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ABSTRACT 


The  technique  of  problem  solving  abstraction  provides  an 
appropriate  tool  for  specifying  an  interface  between  the  layers 
of  computer  hardware  and  software.  Based  on  this  methodology, 
the  types  of  support  and  function  calls  that  should  be  pro¬ 
vided  to  application  programs  running  on  micro  computers  are 
described  with  respect  to  a  database  resource.  The  database 
is  integrated  with  an  abstract  processor  called  AM,  a  machine 
which  focuses  on  eliminating  the  problems  with  portability 


and  reusability  of  software,  imposed  by  insufficient  resource 


abstraction . 
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INTRODUCTION 


I . 

Traditionally,  computer  software  evolved  in  connection 
with  a  particular  hardware  environment,  and  often  assumed 
features  closely  related  to  characteristics  of  the  underlying 
hardware.  These  so-called  closed  systems  usually  have  a  unique 
set  of  resources  in  both  hardware  and  software.  However,  as 
systems  became  more  general  purpose,  the  requirement  for  porta¬ 
bility  and  reusability  of  resources  across  systems  increased 
and,  consequently,  the  need  for  creating  greater  resource 
abstraction  arose  [Ref.  1]. 

The  problem  of  formalizing  the  relationship  between  hardv;are 
and  software  resources  was  first  addressed  by  Yurchak  [Ref.  2] 
whose  efforts  resulted  in  the  specification  and  implementation 
of  an  abstract  machine,  called  AM. 

New  data  types  necessary  to  represent  the  abstraction  of  a 
bit-mapped  display  resource  were  added  to  A>;  by  Hunter  [Ref.  3] 
thereby  creating  Ai'l  (version  2.0)  as  a  derivation  of  version 
1.0. 

This  present  research  again  is  an  extension  of  the  work 
begun  by  Yurchak  and  Hunter  with  the  goal  to  design  and  for¬ 
mally  specify  a  portable,  reusable  abstract  database  (version 
3.0).  Its  two  major  objectives  are: 

-  investigate  an  appropriate  methodology  to  specify  an 
interface  between  the  layers  of  computer  hardware  and 
software ; 


\ 

k 
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-  find  a  way  for  applying  such  a  methodology  in  order  to 
describe  the  interface  of  a  computing  system,  with 
respect  to  a  database. 

The  following  is  a  modification  of  the  introduction  presented 
by  Yurchak  [Ref.  2]  and  Hunter  [Ref.  3],  and  contains  some  of 
their  ideas  which  contributes  to  a  better  understanding  of  the 
background  and  motivation  for  this  research. 


A.  THE  PORTABILITY  PROBLEM 

It  is  well  known  that  porting  large  programs  from,  one  machine 
to  another  is  an  expensive  ordeal.  It  is  also  well  known  that 
once  the  software  has  been  moved  to  the  new  machine,  it  is 
anybody's  guess  whether  or  not  it  will  be  work  as  before.  Even 
if  our  program  seem.s  to  work,  we  may  find  it  consumes  more  re¬ 
sources  than  we  expected.  Indeed,  this  may  be  just  as  bad  as 
if  it  did  not  work  at  all. 

There  are  a  number  of  reasons  why  the  portability  problem 
is  getting  worse,  not  better: 

-  most  architectures,  even  those  which  profess  to  be 
"language  directed,"  reflect  a  bias  toward  making  the 
machine  look  like  what  the  programmer  wants,  or  toward 
some  engineering  goal,  such  as  maximizing  the  number  of 
devices ; 

-  both  languages  and  machines  are  related  to  the  data  they 
manipulate  in  an  implementation  dependent  way; 

-  language  and  hardware  designers  pursue  their  conflicting 
goals  to  the  detriment  of  the  poor  compiler  writer,  who, 
with  imprecise  tools  and  methodologies  is  faced  with 
the  job  of  implementing  ambiguous  semantics  on  an 
informally  designed  resource. 


Although  these  and  other  factors  do  adversely  contribute  to 
the  imperfect  task  of  moving  software  from  one  machine  to 


another,  they  add  their  weight  to  other  difficult  issues  in 
language  design,  computer  architecture,  and  software  engineer¬ 
ing.  This  study  confines  itself  to  treating  the  issues  surround 
ing  the  interaction  between  programmer's  view  of  the  world  as 
a  problem,  and  the  architect's  view  of  the  world  as  a  resource. 

The  existing  problem  can  widely  be  described  as  a  matter 
of  unsufficient  resource  abstraction.  And  there  are  examples 
that  demonstrate  the  advantages  brought  along  by  consequently 
applied  resource  abstraction.  For  instance,  many  operating 
systems  (OS)  already  provide  a  uniform  and  functional  interface 
to  the  file  system,  and  combined  with  a  high  level  language  and 
its  associated  runtime  services,  achieve  a  high  degree  of  soft¬ 
ware  portability  [Ref.  1].  Current  research  work  in  the  area 
of  database  machines  indicates  attempts  to  develop  a  system  that 
would,  like  the  OS,  provide  a  uniform  interface,  the  first  step 
towards  portability  and  reusability.  And  this  trend  should  give 
some  reason  to  be  a  little  more  optimistic. 

1 .  Abstraction 

"Abstraction"  describes  the  separation  of  the  defining 
properties  of  an  object  from  other,  unnecessary  details  about 
it.  A  programmer  is  primarily  concerned  with  solving  a  prob¬ 
lem.  Appropriately,  the  tools  at  his  disposal,  programming 
languages,  development  aids,  the  programming  environment,  form 
a  "problem  solving  abstraction."  The  hardware  (and  some  of 
the  software)  on  which  this  problem  solving  abstraction  is 
implemented,  however,  is  an  abstraction  of  a  different  sort. 


Addresses,  registers,  ports,  most  of  the  operating  system 
service  routines,  all  provide  more  or  less  efficient  ways  to 
manipulate  the  physical  resources  of  the  machine,  they  form  a 
"physical  resource  abstraction." 

The  fuzzy  area  between  these  two  abstractions,  sometimes 
simplistically  perceived  as  the  boundary  between  hardware  and 
software,  exposes  a  number  of  shortcomings  in  language  design 
and  computer  architecture  collectively  termed  the  "semantic 
gap.  " 

As  mentioned  before,  proper  resource  abstraction  plays 
a  major  role  in  the  attempt  to  resolve  the  portability  problem. 
In  areas  other  than  the  operating  systems,  abstraction  however, 
seems  to  be  rather  difficult.  Processors  and  visual  displays 
are  examples.  The  inability  to  establish  a  meaningful  abstrac¬ 
tion  has  impeded  the  formation  of  standard  functional  inter¬ 
faces  to  these  resources.  Operating  systems  generally  do  not 
provide  a  functional  interface  to  either  the  processor  or  the 
display.^  Programs  which  access  these  resources  directly, 
simply  are  not  portable.  High  level  languages  (HLL)  partially 
fill  the  gap  left  by  OFs  for  the  processor  resource.  Unfor¬ 
tunately,  the  interface  level  is  high  enough  to  force  many 
applications  to  bypass  the  HLL  for  efficiency.  Special  graphics 
packages  that  extend  the  OS  provide  similar  services  for  the 
display  resource.  But  despite  these  efforts,  the  problem  is 

^except  in  the  most  rudimentary  way,  OS  function  calls  to 
the  display  are  usually  limited  to  character  and  string 
output. 


still  far  from  solved.  The  lack  of  formal  means  to  specify  the 
interface  that  the  operating  systems,  high  level  languages  and 
graphics  packages  attempt  to  provide  is  a  serious  shortcoming 
that  impedes  portability. 

The  same  applies  for  database  systems,  too,  which  al¬ 
though  more  recently  introduced  in  computer  history  not  only 
offer  a  whole  set  of  different  and  incompatible  database  models 
from  which  to  choose,  but  also  force  the  implementor  to  adopt 
the  corresponding  query  language.  The  latest  development  is 
towards  the  so-called  backend  approach  that  reduces  the  workload 
of  the  host  computer  in  a  very  impressive  way  by  separating 
the  database  part  from  the  mainframe  and  letting  it  run  as 
autonomously  as  possible;  but  the  above  described'»interf ace 
problem  remains  unsolved.  Thus,  at  present  the  variety  that 
originally  was  created  to  optimize  a  data  base  to  meet  the 
respective  goals,  strongly  interferes  with  the  idea  of 
reusability . 

2 .  The  Semantic  Gap 

The  semantic  gap  manifests  itself  anywhere  a  problem 
solving  abstraction  touches  a  physical  resource  abstraction. 

A  detailed  description  may  be  found  in  Myers  [Ref.  4].  He 
observes  that  the  semantic  gap  contributes  to  the  cost  of 
software  development,  software  unreliability,  inefficiency, 
complexity,  and  the  distortion  of  programming  languages.  Cer¬ 
tainly  no  single  development  or  methodology  will  eliminate  this 
problem. 
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SIVIV 


Narrowing  the  semantic  gap  requires  significant  changes 
in  the  fundamentals  of  computer  architecture  and  language  design 
We  chose  to  concentrate  on  three  factors  which  significantly 
contribute  to  this  problem: 

informally  described  semantics; 

representation  dependent  data  types; 

arbitrarily  designed  instruction  set  architectures. 

The  implication,  of  course,  is  that  through  increased  formalism, 
the  introduction  of  representation  independent  data,  and  a  more 
throughtful  treatment  of  the  instruction  set,  the  sem.antic  gap 
can  be  narrowed.  The  balance  of  this  thesis  is  devoted  to 
describing  a  methodology  for  doing  just  that. 

B.  THREE  WAYS  TO  NARROW  THE  SEMANTIC  GAP 
1 .  Formalism 

The  benefits  of  formalism  in  the  design  process  have 
been  amply  revealed  in  countless  articles  treating  this  issue 
from  the  standpoint  of  software  engineering.  Our  concern  will 
be  limited  to  formalism  as  it  applies  to  the  specification  of 
an  abstraction.  Various  specification  methodologies  exist, 
many  of  which  have  been  used  with  more  or  less  success  in  pro¬ 
jects  of  practical  significance.  But  we  caution  the  reader 
that  by  "formal"  we  mean  a  mathematical  rigor  rooted  in  proven 
theory.  The  idea  of  formalism  as  often  applied  to  software 
engineering  will  not  do  here.  A  "formal  specification"  is  a 
complete  description  of  the  meaning  of  an  object.  It  forms  the 


basis  for  an  abstraction  and  is  ultimately  a  bridge  over  the 
semantic  gap. 

The  benefits  of  formalism  in  which  we  are  most  inter¬ 
ested  are: 

it  provides  a  firm  basis  for  proving  our  assertions 
about  a  specification  and  its  implementation; 

it  encourages  a  discipline  on  the  part  of  the  designer 
to  be  rigorously  precise; 

it  compels  us  to  find  ways  of  describing  things  which 
are  (implementation)  independent. 

2 .  Representation  Independence 

Conventional  machines,  in  contrast  to  the  Ali,  force 
us,  as  programmers,  to  develop  our  own  abstractions  of  data. 

At  a  time  when  we  are  most  concerned  with  developing  clean 
algorithms  the  architecture  obligates  us  to  worry  about  status 
registers  and  word  length.  Certainly  someone  must  ultimately 
deal  with  these  physical  properties  of  the  hardware,  but  this 
should  not  fall  as  an  "obligation"  upon  the  programmer.  The 
programmer  should  be  free  to  ignore  unnecessary  detail. 

Displays  are  equally  difficult.  Often  the  programmer 
is  forced  to  deal  with  display  data  at  a  very  low  level.  In 
order  to  create  his  display,  it  may  be  necessary  for  him  to 
work  at  a  level  of  poking  bits  out  the  processor  port  to  the 
terminal.  By  defining  data  types  that  include  objects  which 
represent  concepts  appropriate  to  visual  display  processing, 
the  programmer  will  be  freed  to  work  at  a  higher  conceptual 


level . 


Due  to  the  comition  nature  of  this  problem,  with  the 
database  we  find  ourselves  in  a  situation  not  much  simpler 
than  the  one  just  described.  Since  a  single  database  is  usually 
designed  to  fulfill  only  a  very  specific  task,  for  instance, 
running  the  passenger  reservation  system  for  an  airline,  first 
of  all  the  logical  structure  of  the  database  to  be  created  must 
be  dovelcped.  This  can  be  done  using  a  data  structure  diagram 
which  contains  all  the  required  entities  including  the  relation¬ 
ship  among  them.  But  while  this  step  is  achievable  without 
consideration  of  the  later  implementation,  we  have  to  give  up 
this  kind  of  abstraction  in  the  second  phase  when  the  diagram 
is  transformed  into  a  design  that  conforms  to  the  limitations 
and  peculiarities  of  a  given  database  management  system  (DBMS). 
The  programs  themselves  which  may  be  created  in  parallel  with 
the  development  of  the  logical  database  structure  must  apply 
to  the  standards  of  the  database  type  chosen,  thus  putting  the 
programmer  in  a  similar  situation  as  for  all  conventional 
machines . 

We  will  attempt  to  minimize  the  dependence  of  data  upon 
its  representation  through  the  use  of  "abstract  data  types." 

Our  notion  of  data  is  very  general.  It  ranges  from  integers, 
to  image  and  database  objects,  and  to  program  instructions. 

Data  type  representation  will  be  hidden  and  abstract  operations 
will  be  provided  in  the  same  way  as  with  traditional  abstract 
data  types.  If  these  data  types  can  be  kept  representation 
independent,  then  portability  is  aided. 


Intent  Expressive  Resource  Abstraction 


Conventional  architectures  do  not  permit  us  to  unam¬ 
biguously  express  our  intent  in  a  program.  Artificial  data 
types,  combined  with  typical  resource  models,  force  ambiguity 
and  the  overloading  of  data  structures.  Stack  frames  are  a 
good  example  of  this.  The  semantics  of  the  frame  combine  those 
of  an  array  and  those  of  a  stack.  Meanwhile,  the  whole  thing 
is  implemented  in  memory,  with  the  data  types  overlaid  on  an 
array  of  fixed  length  cells. 

We  claim  that  applying  methods  similar  to  those  used 
to  describe  abstract  data  types,  we  can  describe  an  abstraction 
of  the  physical  resource  of  a  machine  which  benefits  not  only 
from  the  formalism  used  to  specify  it,  but  also  permits  the 
implementor  to  clearly  interpret  the  intent  of  programs  v;ritten 
for  it. 

C.  METHODOLOGY 

The  goal  of  the  research  done  by  Yurchak  and  Hunter,  and 
now  of  this  thesis  is  to  contribute  something  of  practical 
significance  to  the  study  of  software  portability  by  treating 
an  area  which  has  been  largely  ignored,  the  design  of  a  formal 
abstraction  for  the  computing  machine  itself.  We  have  innumer¬ 
able  high  level  programming  languages,  programming  environments, 
graphics  languages,  database  machines  (backend  processors), 
query  languages,  file  systems,  operating  system  command  inter¬ 
preters,  a  whole  host  of  different  abstractions  tailored  to  the 


task  of  providing  us  with  just  enough  information  to  do  every¬ 
thing  we  need  to  do,  and  nothing  more.  So  why,  then,  have  we 
failed  to  develop  abstractions  for  the  hardware  resources,  upon 
which  we  are  so  dependent,  which  are  more  than  just  a  collection 
of  registers,  opcodes  and  some  arbitrary  rules  about  how  they 
interact.  A  more  difficult  but  certainly  more  important  task 
than  actually  defining  the  abstraction  is  developing  a  methodology 
for  producing  other  resource  abstractions. 

Our  method  has  been  to  take  a  naive  approach  towards  all 
areas  of  the  design  and  implementation  process  not  directly 
related  to  the  specification  itself.  We  do  this  for  two 
reasons.  First,  we  can  take  for  granted  the  large  body  of 
research  in  programming  languages  and  computer  architecture, 
we  are  designing  neither  a  language  nor  a  processor,  even  though 
"ad  hoc"  examples  were  required  to  complete  the  implementation. 
Second,  the  research  is  intended  to  benefit  programmers.  Since 
it  is  unreasonable  to  expect  those  who  may  use  this  method  to 
understand  the  theory  behind  the  specification,  the  key  to 
understanding  the  reasons  for  our  design  decisions  lies  in  the 
way  we  coded  it.  Thus,  cleverness  has  been  eschewed  in  favor 
of  clarity. 

Our  task  in  this  thesis,  then,  is  to  examine  a  wide  range 
of  issues  which  impinge  on  the  process  of  designing  and  imple¬ 
menting  the  specification  of  a  database  system,  and  then  to 
describe  how  we  went  about  actually  doing  it. 


II . 


THEORY 


The  formal  specification  method  used  to  define  the  Abstract 
Machine  (AM)  is  based  on  algebraic  semantics.  This  approach 
was  chosen  because  algebras,  due  to  their  hierarchical  struc¬ 
ture,  enable  us  to  deal  with  complex  problems  or  to  control 
com.plex  situations  by  decomposing  them  into  simpler  subproblems 
with  clearly  determined  interfaces. 

Clean  interfaces,  on  the  other  hand,  provide  a  sound  basis 
for  modifying  or  combining  existing  programs,  which  is  our  in¬ 
tention  in  advancing  AM  from  version  2.0  to  version  3.0.  But 
algebraic  semantics  also  contribute  to  solve  the  portability 
problem  for  software  systems,  since  they  represent  a  high  level 
of  abstraction  which  is  the  only  promising  means  to  narrowing 
the  semantic  gap. 

Abstraction  allows  us  to  deal  with  concepts  apart  from 
particular  instances  of  those  concepts  and  to  concentrate  on 
the  essentials  only.  Abstract  data  types  are  the  fundamental 
elements  a  formal  specification  is  built  upon.  Guttag  [Ref.  5] 
states  that  to  describe  an  abstract  data  type  precisely,  its 
specification  must  comprise  both  the  syntax  and  the  semantics. 

According  to  Guttag,  a  formal  specification  should  meet 
the  following  criteria,  which  were  taken  from  Hunter  [Ref.  3], 
if  it  is  to  be  useful: 


it  must  be  restrictive  enough  to  ensure  that  nothing 
unacceptable  to  the  specifier  will  meet  the  require¬ 
ments  imposed  by  the  specification; 

it  must  be  sufficiently  general  to  ensure  that  few,  if 
any,  acceptable  entries  are  precluded; 

it  must  be  understandable,  so  people  can  work  with 
it. 

From  [Ref.  2],  we  note  that  to  achieve  true  portability,  we 
must  be  able  to  demonstrate  the  following  properties  in  our 
implementation : 

the  specified  semantics  actually  implemented  on  the 
source  machine  are  completely  unambiguous; 

the  implementation  on  the  source  machine  is  "correct." 

Thus,  our  method  of  specifying  must  be  formal  enough  to  permit 

proofs  of  correctness.  Exhaustive  testing,  however,  especially 

when  dealing  with  complex  specif ications ,  is  usually  not 

feasible  and  so  the  only  true  statement  we  can  make  is  that 

our  specification  is  correct  at  least  with  regard  to  those 

tests  actually  performed. 

Algebraic  specifications  meet  the  above  criteria  for  achiev 
ing  true  portability.  Here  we  find  a  significant  body  of  re¬ 
search  already  in  place  in  the  area  of  abstract  data  type 
specification.  Goguen  [Ref.  6]  and  Guttag  [Ref.  5]  treat  this 
topic  in  great  detail.  We  will  not  so  here.  Instead  we  give 
an  overview  of  the  important  concepts  of  abstract  data  types, 
and  direct  the  reader  to  the  original  works  for  more  in-depth 
study  of  the  underlying  thoery.  Davis  [Ref.  7]  provides  the 
theoretical  basis  for  the  resource  specification  method. 


Davis  [Ref.  1]  also  provides  additional  background  but  with 
an  emphasis  on  practical  issues. 

A.  ABSTRACT  DATA  TYPES 

The  underlying  principle  that  gives  mathematics  the  power¬ 
ful  tool  for  generalization  is  its  intention  to  specify  the 
fundamental  nature  of  a  system  by  stating  only  a  few  basic 
propert.os.  j.n  order  to  describe  an  entire  system  by  means 
cf  a  small  number  of  its  characteristics  it  is  necessary  to 
find  out  what  exactly  these  characteristics  are  and  how  to  state 
them  in  terms  that  define  all  the  systems  of  this  particular 
category.  This  can  be  achieved  effectively  by  applying  the 
technique  of  data  abstraction,  which  is  a  synonym  for  the  term 
"abstract  data  type." 

In  general,  abstract  data  types  refer  to  the  fact  that 
permissible  operations  on  the  data  ojects  are  emphasized, 
while  details  about  the  representation  of  the  data  objects 
are  suppressed.  Because  data  abstraction  focuses  mainly  on 
functional  properties  but  ignores  unimportant  things  like 
representation  details,  only  some  of  the  many  possible  func¬ 
tional  properties  have  usually  to  be  specified.  This  allows 
us  to  define  even  complex  systems  by  means  of  abstract  data 
types,  or  in  other  words,  via  certain  sets  of  data  values  to- 
gether  with  the  corresponding  sets  of  primitive  operations  on 
those  values. 

The  properties  of  abstract  data  types  again  are  specified 
by  algebraic  axioms  which  define  all  mathematical  systems  and 
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provide  the  basis  for  deriving  additional  properties  that  are 
implied  by  the  axioms.  This  will  be  discussed  in  more  detail 

t 

later  in  this  chapter. 

The  stack,  queue,  or  list  serve  as  typical  examples  to 
demonstrate  how  data  abstraction  works;  all  of  them  can  be 
characterized  by  simply  defining  the  essential  operations  that 
may  be  performed  on  each  individual  system.  For  example,  a 
list  could  be  characterized  by  operations  such  as  NIL  that 
creates  an  empty  list,  FIRST  that  returns  the  first  member  of 
the  list,  PREF'''X  that  adds  a  new  member  to  the  front  of  the 
list,  and  NULL  that  tests  for  an  empty  list.  Using  this  ap¬ 
proach  the  programmer  need  not  care  about  how  the  list  and 
its  manipulating  functions  are  actually  implemented,  which 
allows  him  to  concentrate  on  his  programming  job.  And  this 
principle  definition  of  the  list  can  be  used  for  all  systems 
of  type  "list"  because  the  description  has  been  kept  very  general 
by  means  of  abstraction. 

Besides  providing  us  with  a  very  important  mechanism  for 
writing  well-structured  programs,  abstract  data  types  make 
program  modifications  easy.  As  long  as  the  interfaces  of  the 
manipulating  functions  remain  unchanged,  internal  details  may 
be  modified  without  affecting  other  program  components  in  an 
unwanted  way. 

Thus,  in  applying  the  methodology  of  data  abstraction  we 
are  forced  to  clearly  specify  our  intentions,  which  in  many 
situations  is  the  stimulus  to  think  intensively  about  what  a 
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system  really  is  or  does,  and  then  to  describe  the  result  in 
an  unambiguous  manner.  Due  to  its  clear  style  and  high  level 
of  abstraction,  the  so-defined  system  not  only  is  independent 
of  its  originator,  but  is  also  easier  to  understand. 

B.  STRUCTURES 

So  far  we  have  discussed  how  to  use  the  mechanism  of  abstrac 
tion  in  order  to  handle  complex  systems  but  we're  primarily 
concerned  with  the  consideration  of  the  permissible  operations 
on  those  systems,  like  the  PREFIX  operation  for  lists.  In  this 
paragraph  we  will  now  examine  the  more  systematic  definition  of 
structures.  Clocksin  [Ref.  8]  defines  a  structure  as  a  single 
object  that  consists  of  a  collection  of  other  objects,  called 
components.  The  components  are  grouped  together  to  a  single 
structure  for  convenience  in  handling  them.  Thus,  a  structure 
can  be  characterized  by  the  kind  of  its  components  and  the  way 
they  are  arranged.  Structures  are  helpful  in  organizing  data 
since  they  allow  a  group  of  related  information  to  be  considered 
as  a  single  object  instead  of  different  ones.  The  decomposition 
of  data  into  individual  components  depends  solely  on  the  pur¬ 
pose  which  is  to  be  achieved  in  solving  the  particular  prob¬ 
lem;  so  it  is  up  to  the  programmer  to  create  the  structures  that 
contribute  most  in  reaching  his  intended  goal. 

To  return  to  our  former  example,  the  list,  which  is  a  struc¬ 
ture  itself,  what  exactly  are  the  kinds  of  components  and  their 
allowable  arrangements?  For  the  list  as  an  ordered  sequence  of 


elements  the  order  of  the  elements  in  the  sequence  matters,  or 
as  stated  in  MacLennan  [Ref.  9],  the  allowable  arrangements  are 
finite  linear  o-derings.  The  components  of  a  list  may  be  any 
terms,  including  constants,  variables,  booleans,  and  lists 
themselves.  Due  to  these  properties  lists  can  represent  prac¬ 
tically  any  kind  of  structure  that  might  be  convenient  for 
svmibolic  computation. 

So,  for  e.xample,  if  one  would  like  to  describe  a  thing  on 
the  basis  of  certain  attributes  corresponding  to  it,  the  enumer¬ 
ation  of  these  attributes  could  be  considered  as  creating  a 
list  by  vmich  this  thing  can  be  defined: 

thing:  attributej,,  attribute^  ,...,  attribute^ 

Bringing  the  attributes,  or  components  of  the  list,  then  into 
a  particular  oder  and  specifying  the  values  they  may  take,  enables 
us  to  create  classes  of  related  lists.  This  can  be  very  useful 
in  grouping  things  of  the  same  type  together,  as  it  is  the  case 
in  all  database  systems: 
class : 

thing^:  ^ attribute^ ^ ,  attribute^^ ' • • • ' 3ttribute^^> 

thing^  :  ^  attr ibute2 ,  attribute22  '  •  •  •  '  attribute^^  > 

thing  :  -attribute  ,,  attribute  ^  ,...,  attribute  '■ 

^m  ml/  m2  mn 

This  simple  example  will  be  discussed  in  much  more  detail  in 
the  following  chapters. 

In  the  previous  paragraph  we  have  already  determined  the 
primitive  operations  performed  on  lists.  There  are  three 
classes  of  operations  on  structures  in  general: 


constructors  which  allow  us  to  build  a  structure  in 
accordance  with  its  predefined  characteristics  (like 
PREFIX  for  lists) ; 

selectors  which  allow  us  to  obtain  a  component  from 
the  structure  (like  FIRST)  ; 

predicates  which  allow  us  to  determine  the  arrangement 
of  the  components  in  a  given  structure  and  return  a 
boolean  value  (like  NIL) . 

Depending  on  the  kind  of  structure  one  wishes  to  describe, 
there  is  a  certain  number  of  operations  required;  for  lists 
it  turns  out  that  just  six  operations  (two  for  each  construc¬ 
tor,  selector,  and  predicate)  are  sufficient,  while,  for 
example,  the  description  of  a  stack  would  require  only  five 
operations  (NEW  and  PUSH  as  constructors,  POP  and  TOP  as 
selectors,  EMPTY  as  predicate): 


STACK 

CONSTRUCTORS 

SELECTORS 

PREDICATES 

empty 

NEW 

- 

EMPTY 

nonempty 

PUSH 

POP 

- 

TOP 

But  apart  from  the  number  of  actual  operations  which  is  varia¬ 
ble,  the  three  fundamental  classes  of  operations  remain  un¬ 
changed  for  any  structure.  And  there  is  one  more  point  that 
should  be  mentioned:  Selectors  and  constructors  invert  each 
other  in  some  cases.  For  example,  for  the  stack  we  have 

POP (PUSH (stack, X) )  =  stack 


which  means  that  pushing  an  item  X  onto  a  stack  and  immediately 
popping  it  off  again  leaves  the  stack  unchanged.  The  same 


would  be  true  for 


PUSH (POP (stack) ,Y)  =  stack 

if  the  same  item  Y  just  popped  off  the  stack  was  immediately 
pushed  back  onto  the  stack  again. 

But  as  fine  as  the  inversion  of  selectors  and  constructors 
works  for  stacks  (unrestricted  in  the  case  of  POP (PUSH))  or 
for  lists,  it  would  not  work  for  queues  because  items  are  then 
added  to  the  rear  end  while  always  removed  from  the  front. 
Keeping  these  correlations  in  mind  makes  it  easier  to  develop 
our  algebraic  specification  later. 

C.  ALGEBRAIC  SPECIFICATIONS 

Specifications  are  particular  and  detailed  descriptions  of 

things;  they  contain  essential  information  about  the  dimensions 

and  peculiarities  of  the  described  objects.  They  furthermore 

represent  a  convenient  way  to  describe  the  generally  infinite 

objects  of  initial  algebras  in  finite  terms  if  we  want  to  build 

our  abstract  data  types  on  an  algebraic  basis. 

Such  a  specification  is  also  known  as  "operator  signature" 

and  consists  of  two  major  components: 

the  syntax  whose  purpose  is  to  define  the  constants  and 
operations  as  well  as  the  axioms  as  intermediate  step 
in  developing  the  semantics. 

the  semantics  of  the  data  type  as  part  of  the  realization 
which  is  mostly  of  concern  for  the  implementation. 

In  mathematical  notation  a  specification  can  be  seen  as  a 

triple  <S,Z,p:>  where  1  is  a  S-sorted  signature  (this  means,  it 


is  based  on  the  operands  of  sort  S)  and  e  is  a  set  of  --equa¬ 
tions.  Here  <S,Z,z>  specifies  an  abstract  data  type  by  defin¬ 


ing  T-  _  which  represents  an  isomorphism  class  of  S-algebras. 

^  f  Z, 

An  algebraic  specification  represents  something  between  our 
intuitive  sense  of  what  we  want  and  the  actual  computer  code. 
This  characteristic  feature  facilitates  the  translation  of  our 
ideas  into  working  programs  and  narrows  the  scope  of  possible 
interpretation  by  the  application  programmer.  It  also  allows 
us  to  augment  an  existing  data  type  by  introducing  so-called 
derived  operators  without  the  need  for  rewriting  the  initial 
operations,  or  to  extend  existing  specifications  to  make  their 
data  types  available  to  others,  thus  avoiding  unnecessary 
redundancy . 

1 .  Syntax  Part 

The  definition  of  an  abstract  data  type  itself  should 
tell  us  all  we  need  to  know  for  using  it  effectively.  But 
first  of  all,  how  can  we  be  sure  that  we  have  selected  the 
correct  level  of  abstraction  to  begin  with?  MacLennan  [Ref. 

9]  states  that  there  is  in  fact  no  formula  for  calculating 
such  a  correct  level,  it  rather  depends  on  our  individual  view 
of  the  world  and  our  needs  at  the  moment.  The  chosen  approach 
should,  however,  guarantee  that  it  really  models  our  abstrac¬ 
tion  of  the  part  of  the  world  we  want  to  describe. 

So,  in  order  to  start  we  list  the  constants  and  the 
primitive  operations  on  the  data  types  to  be  defined  and,  in 
doing  so,  we  create  the  legal  ways  in  which  expressions  in¬ 
volving  these  data  types  can  be  constructed. 


For  each  primitive  operation  it  is  necessary  to  explicitly 
state  the 

name  of  the  operation; 
type(s)  of  its  argument(s); 
type  of  value  returned; 

thereby  setting  the  domain  of  the  arguments  and  value  for 
each  operation: 

operation :  { argumenttype^ , arguinenttype2 » • . • , argumenttype^)  value type ; 

As  an  example,  the  syntax  for  integer  addition  could  be  written 
in  the  following  way: 

add  (integer,  integer)  integer; 

The  syntax  chart  for  the  general  case  which  is  a  modification 
of  the  charts  usually  found  in  the  ADA  programming  language  is 
shown  in  Figure  II. 1. 


Figure  II. 1.  Syntax  Chart 


In  short,  the  purpose  of  specifying  the  syntax  of  an  abstract 
data  type  is  to  define 

1)  the  legal  forms  of  expressions,  and 

2)  the  way  in  which  the  constants  and  operators  can  be 
combined  into  expressions. 


Generally,  it  seems  to  be  wise  to  build  specifications  in  a 
bottom-up  way,  which  means  starting  with  the  most  primitive 
type  of  data  and  then  proceeding  in  gradually  reaching  a  higher 
level  of  abstraction  on  the  basis  of  the  more  elementary  types 
while  hiding  the  details  of  the  lower  levels. 

But  in  spite  of  this  approach,  each  data  type  has  to 
be  considered  independently  of  its  later  implementation  and 
must  be  treated  at  any  given  level  as  if  it  were  itself  a 
primitive  one  which,  on  the  other  hand,  could  lead  to  some 
redundancy . 

2 .  Axiom  Part 

Having  defined  the  legal  (or  well-formed)  expressions 
and  the  types  of  values  they  return  in  a  rather  symbolic  way, 
we  next  consider  the  meaning  of  those  primitive  operations, 
this  means,  answering  the  question  of  what  values  they  in  fact 
compute  when  given  legal  inputs.  This  is  done  in  the  axiom  or 
property  part  of  the  specification  which  therefore  can  be  re¬ 
garded  as  a  refinement  of  the  preceding  syntax  definition. 

Semantics,  in  general,  deal  with  the  actual  realization 
of  our  formal  terms;  here  we  are,  in  accordance  with  our  inten¬ 
tion  to  use  an  abstract  terminology  as  far  as  possible,  not  yet 
interested  in  any  programming  language  that  could  do  the  job, 
but  prefer  to  give  a  set  of  mathematical  equations,  or  axioms, 
which  define  the  meaning  of  the  operations  in  a  way  entirely 
independent  of  the  final  implementation.  This  approach  of 
applying  mathematical  techniques  eases  the  reasoning  about 
well-formed  expressions. 


Trying  to  mathematically  specify  the  axioms  we  face 
the  problem  of  what  it  is  that  has  to  be  specified  and  to 
what  extent.  As  for  determining  the  correct  level  of  abstrac¬ 
tion  to  start  with,  there  is  no  definite  solution  to  this 
problem.  Basically,  we  want  a  set  of  equations  which  defines 
the  properties  of  all  well-formed  expressions.  It  is  mainly 
up  to  the  creator  of  the  specification  to  decide  what  kind  of 
meaningful  interactions  between  the  operators  should  be  included, 
as  long  as  these  equations  are  complete  and  define  the  result 
of  a  function  for  all  legal  inputs. 

For  example,  the  properties  for  the  operation  'integer 
addition/subtraction ' 

+,-  :  ( integer , integer)  integer; 

could  be  described  as  follows: 

a+b  =  b+a; 
a+{b+c)  =  (a+b)+c; 
a+0  =  a; 
a+(-a)  =  0; 
a-b  =  a+ ( -b) ; 

The  final  step  then  would  be  to  find  the  minimum  complete  set 
of  equations,  which  means  listing  only  those  equations  abso¬ 
lutely  necessary  to  define  the  properties  of  the  primitive 
operations,  including  implicit  statements.  But  since  it  is 
sometimes  more  convenient  to  directly  state  equations  which, 
thinking  strictly  mathematically,  are  already  contained  in  other 
statements,  it  is  legitimate  to  introduce  them  as  so-called 
derived  operators. 


/* commutative*/ 
/*associative*/ 
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An  example  of  such  a  derived  operator  is  the  boolean 
function  IMPLIES: 

IMPLIES (X,Y)  =  OR {NOT  X,Y); 

which  is  equivalent  to  the  combination  of  two  simpler  functions 
containing  NOT  and  OR.  By  this  means  we  can  add  new  operations 
and  their  defining  equations  to  a  data  type,  whenever  it  is 
useful  within  the  specification. 

3 .  Problems  with  Algebraic  Specifications 

From  the  preceding  paragraphs  it  should  become  clear 
that  there  is  no  other  way  in  creating  a  database  for  the  Ab¬ 
stract  Machine  except  of  defining  a  formal  specification  first. 
This  gives  us  the  tool  to  concisely  describe  our  intentions  in 
an  unambiguous  and  rigorous  manner.  But  it  also  forces  us  to 
view  the  overall  problem  of  what  a  database  actually  represents 
in  a  strictly  mathematical  way.  This  means,  we  first  must 
determine  the  primitive  names  that  form  the  syntactic  realm  and 
describe  all  legal  operators.  We  then  must  specify  the  corres¬ 
ponding  universe  of  discourse,  which  contains  our  primitive 
objects,  and  the  functions  that  map  each  name  from  the  syntac¬ 
tic  domain  to  its  counterpart  in  the  semantic  domain. 

Although  this  approach  often  does  not  harmonize  with 
our  intuition,  since  the  human  mind  tends  to  be  more  liberal 
than  rigorous,  it  has  the  distinct  advantage  of  providing  us 
with  a  clear  structure  which  is  easier  to  understand  and  where 
each  defined  operation  can  be  proved  correct.  We  consider 
this  basic  type  as  the  mathematical  part  of  the  specification. 


This  method  furthermore  has  the  advantage  that,  given 
the  operation  presently  performed  and  the  current  state  of  the 
machine  which  corresponds,  as  Fairley  [Ref.  10]  states,  with 
.  the  information  required  to  summarize  the  status  of 
system  entities  at  any  particular  point  in  time,  .  .  .  the 
next  state  can  be  determined." 

During  the  research  phase  for  this  thesis,  however,  it 
became  obvious  that  it  often  is  very  difficult  to  translate 
relatively  simple  models  of  the  real  world  into  terms  of  alge¬ 
braic  expressions.  Besides  avoiding  unwanted  inconsistencies 
the  problem  centered  on  the  formal  requirements  for  being  precise 
and  for  specifying  the  fundamental  parts  of  our  database, 
wherever  possible,  by  stating  only  the  absolutely  indispensible 
basic  properties  of  the  system  from  which  all  other  operations 
can  be  derived. 

Thus,  in  the  beginning  of  our  work  the  syntactic  speci¬ 
fication  of  the  stack  operations  was  studied.  But  due  to  its 
last-in  first-out  property  which  is  not  very  helpful  for  data¬ 
base  operations,  the  stack  did  not  provide  the  paradigm  with 
which  to  continue.  As  a  more  suitable  example  that  manifested 
the  difficulties  in  writing  an  algebraic  specification  the 
first-in  first-out  property  of  queues  was  then  examined.  The 
specification  shown  in  Figure  II. 2  is  built  upon  an  example 
given  by  Fairley  [Ref.  10].  In  this  example  (Figure  II. 2), 

CREATE  and  WRITE  are  serving  as  constructors  that  build  up  or 
fill  the  queue.  EMPTY  and  READFRONT  describe  its  behavior. 


Syntax : 


Operation 

Domain 

Range 

CREATE 

{  ) 

—  > 

queue 

WRITE 

(queue, value) 

—  > 

queue 

READFRONT 

(queue) 

—  > 

value 

DELETE 

(queue) 

—  > 

queue 

EMPTY 

(queue) 

—  > 

boolean 

Axioms : 

EMPTY (CREATE)  =  true 
EMPTY  (VJRITE  (queue  ,  value)  ) 

READFRONT (CREATE)  =  error 
DELETE (CREATE)  =  error 
DELETE (WRITE (queue, value) ) 

[  WRITE (DELETE (queue) , value) 

Y  if  EMPTY (queue)  then  value 
READFRONT (WRITE (queue , value ) )  =  ^  else 

I  READFRONT ( queue ) 

Figure  II. 2.  A  Simple  Specification  for  the  Queue 


=  false 


r if  EMPTY (queue)  then  CREATE 
'  else 


DELETE  acts  as  a  modifier  to  the  queue.  While  READFRONT  always 
returns  a  copy  of  the  value  sitting  in  the  front  position,  the 
operation  DELETE  actually  removes  this  value  from  the  queue, 
thereby  changing  the  state  of  the  system. 

The  problem  encountered  here  is  that  we  are  not  able  to 
clearly  define  all  of  the  axioms  but  instead  are  forced  to  make 
some  concessions  in  accordance  with  the  prevailing  state  of 
the  queue.  This  is  caused  by  the  fact  that  the  value  presently 
read  from  the  queue  is  not  necessarily  the  one  entered  last 
(compare  Figure  II. 3). 


n+i 


n+2 


n+1 


n 


^ront 

value 

Figure  II.  3.  The  Queue  Principle 

To  remain  consistent  it  is  therefore  necessary  to  introduce  the 
conditional  "if-else"  statement  for  a  part  of  the  axioms  which, 
on  the  other  hand,  takes  away  some  of  the  simplicity.  Compared 
with  the  stack  operations  where  it  is  sufficient  to  increase 
or  decrease  a  countina  device  by  a  number  of  1  with  each  item 
added  to  or  subtracted  from  the  stack,  the  queue  operations 
require  a  more  sophisticated  mechanism  to  keep  track  of  every 
single  item  in  the  queue,  if  one  really  wants  to  be  precise. 
This  precision  could  b  achieved  by  indexing  the  items  when 
inserted  into  the  queue.  The  syntax  for  these  operations  is 
easily  defined,  as  shown  in  in  Figure  II. 4. 


Syntax : 

Operation 

CREATE 

WRITE 

READFRONT 

DELETE 

EMPTY 


Domain _ Range 

(  )  — >  queue 

(queue , value^ )  -->  queue 

(queue)  -->  valuej 

(queue)  -->  queue 

(queue)  — >  boolean 


Figure  II. 4.  Syntax  Part  for  an  Index  Queue 


But  since  we  have  introduced  the  index  values  "value."  and 

1 

"value "we  now  must  describe  their  particular  properties  in 

% 

the  axiom  part.  This  obviously  is  a  complicated  method  of  des¬ 
cribing  the  relatively  simple  arrangement  of  a  queue  in  terms 
of  an  algebraic  specification,  and  also  proves  to  be  a  rather 
difficult  effort.  But  to  our  knowledge,  there  is  no  really 
elegant  solution  to  this  problem  available  at  the  present  time. 

The  previously  mentioned  indexing  methodology  can  only 
be  simplified  by  reducing  the  queue  to  its  basic  operations  in 
a  similar  way  as  done  with  the  abstract  specifications  for  the 
natur'l  numbers  or  integers.  Here,  for  example,  the  number  1 
is  expressed  by  the  paraphrase  " succnat ( zeronat { )  ),"  and  each 

succeeding  number  can  be  described  by  adding  just  another 
"succnat"  in  front  of  this  fundamental  expression.  Applying 
this  technique  to  the  queue  problem  allows  us  to  keep  track  of 
every  single  value  written  to  the  queue  and  read  or  deleted 


from  it, 


So  instead  of  introducing  the  extra  indexing  operation, 


we  could  integrate  the  state  of  the  queue  ('quaddr')  and  modify 
the  specification  as  demonstrated  in  Figure  II. 5.  On  the 
basis  of  these  few  axioms  it  becomes  possible  to  describe  each 
state  of  the  queue  by  an  appropriate  combination  of  the  given 
operations.  The  following  is  an  example  of  this: 


READFRONT (WRITE (WRITE (INITIALIZEO ,vl) ,v2) )  =  vl;  /*v: value*/ 
READFRONT  (DELETE  (WRITE  (V;RITE  (INITIALIZE  0  ,vl)  ,v2)  )  )  =  v2  ; 
READFRONT  (DELETE  (VJRITE  (INITIALIZEO  ,v)  )  )  =  undef; 

READFRONT  (WRITE  (DELETE  (VJRITEdNITIALIZE  0  ,vl)  )  ,v2)  )  =  v2  ; 


Syntax : 

Operation _ Domain 

INITIALIZE  (qaddr, state) 

READFRONT  (qaddr , State ) 

WRITE  (value , qaddr , state) 

DELETE  (qaddr , state) 

Axioms : 


_ Range 

— >  state 
value 
— >  state 
-->  state 


READFRONT (qaddr , INITIALIZE (qaddr , state) )  =  undef; 

READFRONT (qaddr , WRITE (value , qaddr , INITIALI ZE (qaddr , state ) ) ) 

=  value; 

DELETE (qaddr , INITIALIZE (qaddr, state) )  =  undef; 

DELETE  (qaddr  , WRITE  (value, qaddr,  INITIALIZE  0)  )  =  INITIALIZED 
DELETE (qaddr , WRITE (value, qaddr, state) )  = 

WRITE (value , qaddr , DELETE (qaddr , state )  )  ; 
if  not  (INITIALIZE ( ) ) 

then  READFRONT (qaddr , WRITE (value , qaddr , state) )  = 

READFRONT (qaddr , state)  ; 

end if ; 


Figure  II. 5.  A  Specification  for  the  Queue  Including 
the  State 


From  these  examples,  where  we  omitted  the  arguments  "qaddr"  and 
"state"  in  favor  of  clearness,  the  importance  of  placing  the 
parentheses  into  the  correct  locations  becomes  obvious.  The 
previously  defined  operations  are  illustrated  in  Figure  II. 6. 

A  value  different  from  the  one  residing  in  the  front  position 
can  only  be  read  from  the  queue  after  the  front  value  has  been 
deleted,  so  a 


READFRONT (READFRONT (WRITE ( INITIALI ZE ( )  ,v)  )  ) 


in  (WRITE) 


out  (DELETE) 


> 


val ( n+1 ) 

- > 


queue 


1 — 1 

L  1 

1 

operation 

INITIALIZE 

val  (n) 

val  (2) 

val ( 1 ) 

momentary 

state 

val (n) 

- 1 

val  ( 3 ) 

— 

val  ( 2 ) 

change 

of 

state 

READ 


[  =val ( 1 ) ] 


DELETE 


[erase  val ( 1) ] 


Figure  II. 6.  Illustration  of  Queue  Operations 


would  return  two  times  the  value  "v" ,  which  is  similar  to  the 
corresponding  TOP  operation  for  the  staclc.  Although  by  this 
method  some  of  the  axioms  and  the  " if-then-else"  statements 
could  be  eliminated  and  furthermore,  the  requirements  for  an 
abstract  specification  can  be  satisfied,  it  does  not  seem  to 
be  an  elegant  solution  to  the  queue  problem  either.  The  reason 
for  integrating  this  deviation  into  our  research  wor)<  was  to 
give  the  reader  a  better  understanding  of  the  problems  that 
had  to  be  managed  in  writing  a  formal  specification  for  a 
database,  which  is  not  as  simple  as  the  queue. 

4 .  Error  Handling 

A  major  aspect  in  creating  a  specification  is  how  to 


deal  with  the  situation  should  the  user  manipulate  the  defined 


operations  in  a  way  that  would  result  in  an  error.  Because  it 
is  part  of  the  human  nature  to  fail  once  in  a  while,  vital 
systems  tend  to  be  equipped  with  exception  handling  mechanisms 
which  prevent  the  overall  system  from  breaking  down  and  becoming 
worthless,  should  a  predefined  type  of  error  occur.  This  is 
also  known  as  fault  tolerance  or  lenience,  and  represents  the 
opposite  to  the  more  mathematically  sound  term  "strict,"  where 
a  function  becomes  undefined  whenever  one  or  more  of  its  argu¬ 
ments  are  undefined. 

Error  detection  always  causes  a  great  deal  of  problems, 

and  once  having  been  successful  it  is  a  rather  philosophical 

question  of  how  to  proceed,  as  long  as  a  collapse  of  the  entire 

system  can  be  avoided  and  we  get  the  information  that  a  certain 

error  has  occurred.  In  general,  every  attempt  to  handle  this 

problem  should  be  based  on  the  understanding  that 

any  operation  which  encounters  an  error  is  computationally 
meaningless ; 

if  an  operation  encounters  an  error,  then  any  subsequent 
operation  which  utilizes  the  erroneous  result  must  also 
return  an  error; 

errors  must  not  be  hidden,  but  must  be  known  to  the  user. 
These  statements  were  directly  taken  from  Hunter  [Ref.  3],  since 
he  considerably  modified  the  error  handling  routines  for  the 
Abstract  iMachine  (version  2.0),  which  will  be  discussed  later 
in  this  section. 

One  interesting  but  mathematically  not  indisputable 
approach  was  introduced  by  Guttag  [Ref.  5]  with  the  term 


"undefined"  for  equations  whose  values  were  not  determinable, 
for  example,  when  attempting  to  read  an  item  from  the  empty 
stack 


READ (CREATE)  =  UNDEFINED. 

But  since  the  operation  READ  can  only  return  a  value  from  the 
stack,  we  either  have  to  treat  UNDEFINED  itself  as  a  value  or 
READ  as  an  only  partially  defined  function. 

In  the  meantime,  this  problem  was  solved  by  Davis  [Ref. 

1] ;  his  method  has  been  applied  to  the  AM  specification  and 
will  be  described  below. 

Another  approach  that  was  used  by  Yurchak  [Ref.  2]  for 
the  initial  AJM  (version  1.0)  is  to  modify  the  specification  and 
include  an  error  message.  However,  it  soon  became  obvious,  that 
in  adding  such  an  error  message  to  the  specification,  care  has 
to  be  taken  of  all  the  possible  combinatic  is  the  newly  created 
error  message  could  be  involved  in.  This  is  in  accordance  with 
the  above  listed  understanding  that,  if  we  get  an  error,  any 
operation  on  it  yields  an  error,  too.  But  it  also  means  that 
the  number  of  additionally  needed  error  axioms  quickly  leads 
to  an  extent  which  is  no  longer  reasonable. 

To  get  an  idea  what  dimensions  we  easily  reach  in  order 
to  remain  consistent,  we  only  have  to  consider  the  part  of 
the  specification  for  natural  numbers  that  deals  with  the  special 


error  axioms: 


PREDNAT(ZERONAT()  )  =  NATERROR 
PREDNAT (NATERROR)  =  NATERROR 
SUCCNAT (NATERROR)  =  NATERROR 
SUMNAT (N, NATERROR)  =  NATERROR 
SUMNAT (NATERROR, N)  .  =  NATERROR 
SUMI^AT  ( SUCCNAT  ( M)  ,  NATERROR)  =  NATERROR 
SUBNAT (N, NATERROR)  =  NATERROR 
SUBNAT (NATERROR, N)  =  NATERROR 
MLTNAT (NATERROR, X)  =  NATERROR 


where  NATERROR  w’ould  have  to  be  specified  as  the  extra  operator 
class 


ERROR 

OP 

NATERROR:  — >  NAT. 


Although  these  error  axioms  would  reduce  any  term  containing  an 
error  to  the  error  message  of  the  appropriate  sort,  thus 
eliminating  unwanted  elements  of  the  carrier  of  sort  NAT  in 
the  above  example,  it  is  obviously  not  practical  to  follow  this 
approach.  We  therefore  succeed  with  the  concept  of  "undefined" 
as  introduced  by  Davis  [Ref.  1]  and  described  by  Hunter  [Ref. 

3],  since  this  method  allows  us  to  Jceep  the  number  of  additional 
axioms  manageably  low'. 

The  underlying  principle  is  just  a  different  way  of 
viewing  the  mapping  of  elements  from  a  given  domain  to  their 
images  using  a  certain  function.  For  example,  if  we  let  f  be 
a  function  from  A  to  B  and  let  A'  be  a  subset  of  the  domain  A, 
then  f(A')  denotes  a  subset  of  B,  the  image  of  A'  under  f.  We 
now  consider  A'  as  the  domain  of  our  constants  and  operations 


defined  in  the  syntax  part  of  the  specification.  Furthermore, 
we  are  interested  only  in  the  corresponding  values  they  are 
mapped  to  by  the  function  f  (see  Figure  II. 7),  while  ignoring 
all  the  undefined  operations  in  the  set  A-A ' ,  or  in  other  words 
the  attempt  of  mapping  an  element  from  the  undefined  set  re¬ 
sults  in  an  undefined  value. 


A  B 


Figure  II. 7.  The  Problem  with  Undefined  Operations 

"Undefined"  has  the  following  properties: 

undef  is  used  to  describe  the  illegal  operations; 
if  t  =  undef  then  A  ,  .  .  .  ,  t ,  .  .  .  ,  x^)  =  undef; 

where  "A"  is  any  operator  in  the  specification,  and  "x^"  is 
an  expression; 

any  equation  containing  undef  is  equivalent  to  undef; 

in  a  realization,  if  undef  is  encountered,  the  processing 
halts  immediately  and  an  appropriate  error  message  is 
given. 


So,  instead  of  listing  every  single  possible  NATERROR,  all  we 
have  to  do  is  add  the  axiom 


PREDNAT(ZERONAT()  )  =  undef; 

to  our  specification  of  the  natural  numbers,  which  served  only 
as  an  example  for  the  general  case,  thereby  solving  the  "prede¬ 
cessor  of  zero"  problem  without  the  introduction  of  a  special 
error  operator.  The  effect  is  to  restrict  the  range  of  free 
variables  that  apply  to  an  axiom.  This  becomes  clearer  if  we 
look  at  the  following  construction,  where  we  substitute 
ZEROMAT()  for  the  free  variable  n: 

SUCCNAT(PREDNAT(n) )  =  n; 
now  replace  n  by  ZERONATO 

SUCCNAT(PREDNAT(ZERONAT{)  )) 

SUCCNAT  (undef )  =  ZERONATO; 

undef  =  ZERONATO; 

The  evaluation  of  this  axiom  shows  that  substituting  ZERONAT ( ) 
for  n  leads  to  an  undefined  result,  which  is  quite  correct, 
but  returns  the  appropriate  value  for  all  free  variables 
otherwise. 

Thus,  PREDNAT(n)  does  not  exactly  belong  to  the  set  of 
constants  and  operations  defined  in  A'  because  for  some  cases, 
or  precisely  when  n  is  replaced  by  ZERONAT(),  the  value  it  maps 
to  becomes  undefined.  We  therefore  say  PREDNAT(n)  is  only 
partially  defined  and  must  be  seen,  similar  to  the  POP  operation 
for  stacks  as  a  member  of  the  overlapping  set  of  partially 
defined  operations  (Figure  II. 7). 
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/*axiom  to  start  with*/ 
=  ZERONATO; 


■ 


Analogously,  we  receive  a  similar  result  for  all  those 
specified  data  types  where  a  faulty  user  action  may  turn  out 
as  something  undefined,  like  trying  to  read  a  value  from  the 
empty  stack  or  queue.  And  since  this  method  has  already  been 
applied  to  the  Abstract  Machine  (AM)  by  Hunter,  this  is  one 
more  reason  to  continue  with  it. 


III.  DESIGN  OF  THE  INTERFACE 


Data  that  is  stored  more  or  less  permanently  to  be  manipu¬ 
lated  by  a  computer  resource  represents  in  some  way  a  simple 
database,  where  the  software  which  uses  or  modifies  these  data 
is  known  as  the  database  management  system  (DBMS) .  The  differ¬ 
ence  that  makes  a  database  superior  to  file  processing  systems 
which  can  be  considered  as  predecessors  of  the  database  and 
will  be  widely  replaced  by  this  newer  technology,  is  their 
capability  to  provide  via  the  DBMS  more  information  from  a 
given  amount  of  data.  The  DBMS  itself  is  a  complex  and  usually 
large  program  that  acts  as  a  data  librarian.  If  we  follow  the 
approach  presented  by  Bjorner  [Ref.  11] ,  we  can  view  the  DBMS 
as  the  realization  of  a  certain  database  model;  this  then 
allows  us  to  divide  the  further  treatment  into  the  two  parts 
abstraction  and  realization,  which  correspond  to  the  database 
model  and  the  database  management  system. 

A.  BASIC  DESIGN  PRINCIPLES 

In  this  part  of  our  work  we  are  not  yet  concerned  about  the 
realization  but  rather  concentrate  on  the  problem  of  how  to 
formulate  a  useful  abstraction  of  the  database  resource.  As 
seen,  the  desired  state  of  abstraction  can  be  reached  by  ex¬ 
tracting  the  fundamental  properties  of  the  object  of  concern 
on  a  level  which  suits  our  intentions  best.  A  way  to  do  this 


To  get  started  and  to  make  the  overall  framework  of  a 


database  more  understandable,  models  are  helpful  tools  because 
they  enable  us  to  express  relatively  complex  things  in  a  simpler 
and  more  evident  way.  A  tree  is  often  used  to  represent  the 
data  structure  and  the  relationship  between  different  members 
of  the  database.  One  of  the  typical  requirements  for  a  data¬ 
base  system  is  to  find  a  certain  property  among  stored  objects. 

For  example,  an  object  with  the  properties  A,B,C,D 
could  be  described  by  a  simple  tree  (Figure  III.l),  where  the 
object  is  represented  by  the  root  and  the  properties  by  the 
leaves  of  the  tree. 


O 

] 

A  B  C  D 

Figure  III.l.  Tree  Representation  of  an  Object 

In  combining  different  objects  we  can  create  very  complicated 
trees  (also  called  a  hierarchy)  which  represent  the  relation¬ 
ship  in  a  clear  way  that  otherwise  would  be  difficult  to  des¬ 
cribe.  Our  goal  now  is  to  develop  a  system  that  checks  the 


leaves  of  the  tree  for  a  given  condition  which  could  be  con¬ 
sidered  as  a  step  towards  the  often  applied  function  of  search¬ 
ing  for  a  particular  object  in  a  database. 


2 .  Informal  Strategy 

While  still  ignoring  the  question  whether  such  a  tree 
will  actually  be  represented  as  a  sequential,  linked,  or  in¬ 
verted  list  in  order  to  see  if  a  certain  condition  is  satisfied 
by  any  of  the  objects,  we  can  apply  the  following  informal 
strategy : 

Find  all  stored  members  that  satisfy  condition  B. 

Figure  III. 2  gives  an  example  how  this  informal  strategy  may 
be  used.  Thus,  having  shown  how  the  informal  method  works, 
the  next  step  is  to  find  a  way  of  formally  expressing  this 
strategy . 

3 .  Formalization  of  the  Strategy 

First  we  need  to  identify  the  objects- and  their  proper¬ 
ties.  To  do  this  we  look  one  more  time  at  the  informal  part: 
Find  all  stored  members  that  satisfy  condition  B.  It  is  one 
of  the  advantages  of  the  English  language  that  an  object  is 
always  represented  by  a  noun,  while  adjectives  describe  the 
properties  of  an  object.  In  our  simple  example  this  gives  us 
right  away  'member'  as  the  object  and  'condition  B'  as  the 
required  property.  Next  we  have  to  identify  the  operation 
performed  on  the  object  which  is  not  difficult  either  since 
action  is  described  by  verbs.  In  the  discussed  example,  'find' 
is  the  one  looked  for.  Given  the  objects,  properties,  and  the 
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operations  we  may  perform  on  them,  we  now  can  describe  the 
sequence  of  single  steps  necessary  to  'Find  all  stored  members 
that  satisfy  condition  B'  by  the  relational  diagram  shown  in 
Figure  III. 3. 

Given  this  design,  we  could  continue  and  specify  the 
interface  of  each  box  presented  in  Figure  III. 3.  To  complete 
the  formalization  part  this  would,  indeed,  be  necessary.  But 
we  then  would  also  find  ourselves  right  in  the  middle  of  the 
implementation  which  is  not  what  we  want  at  this  time.  We 
therefore  stop  here  short  of  coming  up  with  a  real  formaliza¬ 
tion.  The  general  idea  about  the  possibilities  to  start 
abstracting  the  resource  however  should  be  a  little  more  obvious 
by  now. 


Figure  III. 3.  Relational  Diagram  of  the  Formalized  Strategy 


B.  BASIC  DATABASE  PRINCIPLES 


Before  we  can  start  specifying  the  database  resource  we 
need  some  understanding  of  the  fundamental  principles  every 
database,  in  general,  is  built  upon.  Although  over  the  recent 
years  there  were  various  approaches  in  this  area  to  make  data¬ 
base  work  more  efficiently,  such  as  the  introduction  of  the 
database  machine  (also  known  as  'backend'),  or  the  continuing 
research  on  the  multi-backend  database  headed  by  Professor  Hsiao 
at  the  Naval  Postgraduate  School,  we  consider  our  database  as 
an  integrated  part  of  the  abstract  machine  built  by  extending 
the  present  AM.  So,  in  order  to  formulate  a  useful  abstraction 
we  have  to  keep  it  simple  and  therefore,  are  interested  only 
in  the  conventional,  single  user  type  of  database. 

A  database  is  in  fact  nothing  more  chan  an  elegant  combina¬ 
tion  of  several  file  processing  systems  under  the  control  of 
the  DBMS  (Figure  III. 4). 


Figure  III. 4a.  Traditional  File  Processing  Approach 


Figure  III. 4b.  Database  Processing  Approach 

For  a  general  view  of  a  database  structure  we  refer  to  the 
architectural  description  presented  by  Deen  [Ref.  13].  It 
is  always  a  major  question  how  to  define  and  treat  data  that 
has  to  be  processed  by  a  machine.  In  the  case  of  a  database 
there  are  as  many  as  five  distinct  levels  data  can  be  viewed 
from,  namely,  in  a  bottom-up  fashion,  the 
physical  level 
storage  level 
global  level 
local  level 
user  level 

The  meaning  of  these  levels  (Figure  III. 5)  is  easier  to  under¬ 
stand  if  we  start  with  the  global  level  which  represents  the 
center  part.  This  level  refers  to  the  overall  logical  descrip¬ 
tion  of  the  entire  database  without  considering  its  storage 
representation.  It  shows  the  logical  relationship  among  the 
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program 


Figure  III. 5.  Architecture  of  a  Database:  The  Five 
Levels  for  Viewing  Data 


objects  of  the  database  and  gives  the  conceptual  view  of  the 
system. 

The  local  level  provides  us  with  a  subset  of  the  database 
described  at  the  global  level.  It  was  introduced  with  the 
intention  to  save  the  application  programmer  the  inconvenience 
of  invoking  the  whole  global  scheme  while  he  usually  is  only 
interested  in  a  few  specific  data  items,  since  his  need  is 
local  and  his  view  is  partial.  So  a  subset  is  the  application 
programmer's  view  of  the  database.  It  is  a  logical  description 


of  the  part  in  which  he  is  interested,  and  therefore  represents 
the  external  view  of  the  system. 

How  the  data  should  be  organized  for  storage  in  the  physi¬ 
cal  device  is  specified  at  the  storage  level  which  consists  of 
entries  for  overflows,  physical  block  sizes,  and  data  placement 
techniques.  Access  paths  can  also  be  specified  here. 

Whereas  global  and  local  level  are  logical  descriptions,  th 
physical  level  is  the  physical  database  itself.  The  database 
is  stored  on  physical  devices  in  conformity  v/ith  the  specifica¬ 
tion  of  the  particular  method  applied  at  the  storage  level, 
where  the  purpose  of  this  method  is  to  optimize  the  overall 
performance  of  the  database  whose  logical  description  is  given 
at  the  global  level.  The  fifth  level  is  the  view  of  the  data¬ 
base  as  seen  by  the  end  user  from  a  remote  terminal  using  a 
special,  high  level  query  language. 

Since  the  view  of  data  at  the  user  level  as  well  as  the 
physical  level  are  not  of  particular  interest  for  our  research, 
we  shall  exclude  it  from  subsequent  discussions,  concentrating 
only  on  the  application  program,  the  storage,  and  the  concep¬ 
tual  (global)  and  external  (local)  view.  The  application  pro¬ 
gram  is  stored  permanently  and  is  always  available  to  the  user. 
It  is  usually  written  once,  or  maybe  a  few  times,  should  the 
database  description  be  changed,  and  can  be  invoked  by  special 
commands.  To  manipulate  data  in  the  database  by  the  applica¬ 
tion  program  a  sublanguage,  the  so-called  query  or  data  manipu¬ 
lation  language  (DML)  is  needed,  one  for  each  host  language. 


The  DML  acts  as  an  interface  language  with  the  database  which 
enables  the  application  prograiraner  to  "navigate"  through  the 
database  with  a  search  strategy  defined  by  the  logical  rela¬ 
tionships  of  his  data  at  the  local  level.  An  application 
program  containing  DML  statements  has  to  be  compiled  either  by 
an  extended  host  language  compiler  or  by  a  special  DML  proces¬ 
sor  followed  by  a  host  language  compiler. 

In  contrast  to  a  typical  compiler  however,  this  device,  the 
first  of  three  major  software  pieces,  also  known  as  query 
processor,  does  not  generate  machine  language  but  rather  a 
sequence  of  commands  that  are  passed  to  other  parts  of  the 
database  management  system.  The  query  processor  needs  to  know 
about  the  structure  of  the  database,  so  it  can  interpret  special 
terms  in  the  context  of  the  particular  system.  This  information 
about  the  database  may  already  be  built  into  the  query  processor 
itself. 

The  output  of  the  query  processor  is  fed  into  the  database 
manager  (Figure  III. 6),  where  it  is  translated  into  terms  the 
third  software  component  in  our  simplified  database  blockdiagram 
the  file  manager,  can  understand,  which  means,  into  operations 
on  files  rather  than  on  the  more  abstract  data  structures  of 
the  database  description  (global  level).  The  file  manager  may 
be  the  general  purpose  file  system  provided  by  the  underlying 
operating  system  (OS) ,  or  it  may  be  a  specialized  file  system 
that  knows  about  the  particular  way  in  which  the  data  is  stored 


in  the  database. 


^  •-  ^  --  ^  • 


Figure  III. 6.  Simplified  Block  Diagram  of  a 
Database  System 


The  overall  software  that  permits  the  use  or  modification 
of  the  data  stored  is  a  DBMS  which  basically  covers  all  the 
software  components  we  are  mostly  interested  in.  So  this  is 
the  point  in  the  system  where  the  abstract  database  resource 


comes  in. 


C.  THE  ABSTRACT  DATABASE  RESOURCE 


The  AM  database  resource  replaces  two  of  the  items  shown 
in  Figure  III. 6,  namely  the  database  manager  and  the  file 
manager.  Figure  III. 7a  shows  the  block  diagram  for  a  database 
system  using  AM,  while  Figure  III. 7b  presents  a  general  view 
of  the  AM  arrangement  within  the  database  system  operation. 
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Figure  III. 7b.  Conventional  Database  System  Operation 

(Compare  Hsiao  [Ref.  14]) 


So  AM  takes  over  right  at  the  boundary  where  the  system  changes 
from  working  on  a  more  abstract  basis  to  an  operation  depending 
on  the  particular  machine  applied.  Since  AM  does  not  include 
the  query  processor,  it  can  not  be  considered  as  a  complete 
replacement  of  the  DBMS  but  instead  covers  only  about  two- 
thirds  of  the  functions  carried  out  by  the  DBMS  before  (Figure 
III. 7b).  We  further  recognize  that  we  did  not  mention  another 
specialized  language,  the  data  definition  language  (DDL), 
which  in  conventional  systems  serves  as  the  tool  to  describe 
the  entire  database  once  the  conceptual  scheme  is  specified. 
However,  to  keep  it  as  simple  and  clear  as  possible  we  do  not 
want  to  introduce  one  more  high  level  language,  and  therefore 
prefer  to  let  this  job  be  done  by  a  special  application  pro¬ 
gram,  using  the  query  processor  as  mediator.  Since  installing 


the  database  is  a  one  time  matter  this  restriction  seems  feasible 


AM's  database  primitives  are  more  low  level  and  cover  less 
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aspects  than,  for  example,  the  CODASYL  model.  But  they  con¬ 
tain  all  the  fundamental  features  for  creating  the  database, 
for  updating  a  given  value,  for  inserting  new  elements  into 
the  database,  and  for  retrieving  special  data.  These  operations 
are  considered  appropriate  for  this  abstract  level,  and  will  be 
discussed  in  a  later  chapter. 

In  a  similar  way  as  for  the  conventional  model,  the  database 
manager  as  the  AM  interface,  which  in  fact  is  just  a  collection 
of  routines,  receives  as  its  input  the  processed  query  primi¬ 
tives  in  a  still  machine  independent  form.-  This,  however,  is 
the  only  kind  of  input  the  database  manager  accepts  because, 
since  the  former  DDL  entries  are  now  handled  by  a  special 
application  program,  there  is  no  need  for  the  manager  to  have 
a  second  input  line.  It  further  should  be  noticed  that  the 
security  aspect,  which  means  permitting  access  to  certain  infor¬ 
mation  stored  in  the  database  to  authorized  persons  only,  as  a 
task  frequently  carried  out  by  the  manager,  has  not  been  taken 
into  account.  This  step  can  be  justified  with  the  definition 
of  our  database  as  a  single  user  system.  Thus,  the  general  idea 
is  to  model  the  database  resource  'on  top'  of  the  existing  AM 
(version  2.0)  by  abandoning  all  of  the  usually  required  high 
level  languages  like  DML  and  DDL,  in  order  to  level  the  re¬ 
sources  with  the  AM  operations,  which  is  the  major  step  for 
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eliminating  the  semantic  gap.  But  in  contrast  to  the  display 
resource  defined  by  Hunter,  AM  is  not  entirely  able  to  oper¬ 
ate  on  the  machine  independent  parts  created  by  a  conventional 
database  system, as  long  as  a  separate  DDL  input  is  involved. 

When  dealing  with  the  physical  resource  the  question  to  be 
asked  first  is  what  purpose  it  is  supposed  to  fulfill.  From 
the  programmer's  point  of  view  the  database  should  enable  him 
to : 

create  objects,  characterized  by  particular  properties; 

connect  the  objects  in  a  logical  way  to  a  file; 

store  the  objects  without  consideration  of  the  physical 
storage  method; 

operate  on  any  of  the  stored  objects  in  an  uncomplicated 
manner . 

In  addition  to  the  standard  file  system  where  the  basic 
operations  'open',  'close',  'read',  and  'write'  will  do,  a 
database  must  also  permit  operations  for  retrieving  a  distinct 
object  from  the  storage,  modifying  it  or  checking  if  a  particu 
lar  object  is  stored  at  all.  The  details  will  be  described  in 
the  next  chapter,  but  in  general,  the  database  represents  the 
state  of  all  the  data  stored  as  files  and  can  be  considered  as 
'just  another'  resource  for  AI-l. 

As  mentioned  before,  the  programmer  has  to  start  his  work 
with  the  creation  of  the  logical  "'concept  tailored  for  the  very 
special  kind  of  database  he  intends  to  build.  By  this  logical 
design,  or  model,  he  copies  that  certain  portion  of  the  real 
world  which  describes  his  view  of  selected  activities  best. 


But  as  with  every  model,  its  capacity  is  limited,  not  all 
aspects  can  be  covered.  Thus,  a  careful  selection  of  those 
portions  which  allow  the  required  logical  operations  is  neces¬ 
sary.  The  tool  for  compressing  the  parts  of  the  real  world  in 
such  a  way  that  they  can  be  stored  within  the  database  is  the 
technique  of  Aggregation  by  forming  a  concept  via  abstracting 
a  relationship  between  other  concepts,  called  components,  and 
Generalization  by  forming  a  concept  via  abstracting  a  class  of 
other  concepts,  called  categories.  These  techniques  will  be 
discussed  in  the  next  chapter. 

Due  to  the  compression  however,  some  questions  now  become 
unanswerable.  It  is  the  task  of  the  database  designer  to  make 
sure  that  those  questions  which  can  no  longer  be  answered  are 
of  the  kind  that  never  will  be  asked. 

The  standard  primitives  in  the  real  world  are  the  objects 
and  certain  properties,  where  objects  as  already  stated,  can 
be  represented  by  nouns  while  properties  can  be  considered 
as  adjectives  that  characterize  the  objects.  We  will  stick  to 
this  notation  concerning  the  primitives  throughout  this  paper 
because  their  meaning  is  more  evident  and  they  represent  the 
most  abstract  level.  This  is  one  of  the  major  differences  to 
a  conventional  database  where  widely  a  different  terminology 
is  used.  The  reason  for  this  is  that  in  a  database  we  actually 
can  not  work  with  the  real  world  primitives  since  a  model  is 
not  the  real  world  itself.  But  instead  we  are  working  with 
representations  of  these  primitives.  So  whenver  a  transaction 


from  the  real  world  into  the  conceptual  world  takes  place,  the 
notation  is  changed  to  indicate  this  step.  In  a  conventional 
design  the  objects  are  represented  by  the  so-called  entities 
which  are,  in  contrast  to  their  physical  implementation,  still 
unrestricted  by  the  constraints  of  the  computer.  Properties, 
in  a  similar  way,  are  represented  by  so-called  attributes  which 
serve  as  a  description  for  the  entities  and,  while  properties 
are  characteristics  of  an  object,  attributes  are  representations 
of  those  characteristics.  Thus,  attributes  are  the  character¬ 
istics  of  the  data  types  (objects)  themselves  and,  in  fact, 
every  entity  has  'certain  named  attributes. 

But  as  stated  above,  we  do  not  follow  this  terminological 
excursion  for  the  sake  of  staying  as  abstract  and  representa¬ 
tion  independent  as  possible.  The  intention  finally,  is  to 
keep  the  structure  simple,  with  emphasis  on  the  permissible 
operations  and  to  prevent  the  programmer  from  leaving  the 
path  of  unambiguity. 

In  AM,  database  objects  are  abstract  data  types.  Concep¬ 
tually,  database  operation  is  accomplished  in  the  following 
way.  Objects  are  initially  brought  in  from  the  disk  and  stored 
in  main  memory.  To  manipulate  an  object,  it  is  first  fetched 
from  its  memory  location.  It  is  then  used  as  an  operand  in 
some  database  operation,  and  the  resultant  object  is  stored 
back  into  memory.  At  any  instance,  the  memory  may  contain 
several  objects,  but  the  terminal  is  directed  to  view  only 
some  selected  object (s)  in  accordance  with  the  operation  just 


being  performed.  When  these  operations  finally  are  completed 
the  objects  temporarily  residing  in  main  memory  are  shifted 
back  onto  the  disk  under  control  of  the  operating  system, 
which  is  not  to  be  discussed  here. 
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SPECIFICATION  METHODOLOGY 


Because  our  database  is  considered  as  an  extension  of  the 
existing  AM  we  continue  the  work  originated  by  Yurchak  [Ref. 

2]  using  essentially  the  same  specification  language  which  will 
be  described  later  in  this  chapter.  However,  before  we  proceed 
with  this,  first  some  understanding  is  required  about  the  ap¬ 
proach  we  took  in  adding  the  database  to  AM.  The  purpose  of 
the  next  section  is  therefore  to  make  the  reader  familiar  with 
the  special  methodology  applied  in  order  to  design  this  resource 
and  the  chronological  steps  that  were  done  until  finally  the 
specification  could  be  developed. 

A.  THE  FUNDAMENTAL  STRUCTURES 

To  define  the  operations  that  legally  can  be  performed  on 
the  abstract  data  types  for  our  database  we  need  some  tools  to 
describe  our  intentions  and  also  to  preserve  the  necessary  level 
of  abstraction.  Since  the  complexity  of  a  database  is  not 
easily  understood,  a  data  model  usually  is  formed  as  the  simpli¬ 
fied  representation  of  a  particular  aspect  of  reality.  In  doing 
so,  the  questions  that  arise  next  are:  what  are  the  elements 
our  model  will  be  based  on,  what  actually  is  it  that  we  would 
like  to  represent  in  a  database,  or  what  are  the  specific  as¬ 
pects  of  the  real  world  we  are  mostly  interested  in?  Without 
claiming  to  be  absolutely  correct  in  the  philosophical  view  of 


things,  the  point  to  begin  with  is  the  fundamental  structure, 
known  as  the  primitives  in  the  real  world. 

The  first  phenomenon  here  is  the  object,  which  may  be  a 
thing,  a  person,  an  event,  an  instruction  or,  in  general,  some¬ 
thing  solid  that  can  be  seen  or  touched.  When  objects  can  be 
put  together  under  a  common  but  more  generalized  notation, 
they  may  form  an  object  class.  But  it  must  be  mentioned  that 
grouping  distinct  objects  together  is  only  achievable  by  ignor¬ 
ing  their  differences  at  the  price  of  losing  some  specific 
information  as  a  concession  to  the  generalization. 

The  characteristic  qualities  owned  by  an  object  are  its 
properties.  For  the  above  given  examples,  it  might  be  the  size 
of  a  thing,  the  name  of  a  person,  the  date  of  an  event,  or  the 
statement  contained  in  an  instruction.  All  the  possible 
instances  of  a  property  again  can  be  grouped  together  into  a 
set  defining  the  domain  of  all  the  values  this  property  legally 
may  take,  which  therefore  will  be  called  'valueset'  in  our 
specification.  This  domain  represents  not  just  a  collection  of 
numbers  or  characters  but  instead  has  to  be  considered  as  the 
set  of  all  values  a  given  property  can  have.  For  example,  for 
the  object  'person'  with  the  property  'name'  the  corresponding 
valueset  would  be  the  collection  of  all  the  names  that  might 
be  found  among  people  on  earth. 

An  example  of  how  objects  and  properties  are  related  to 
each  other  is  given  in  Figure  IV. 1,  which  is  based  on  concept 
developed  by  Kroenke  [Ref.  15:p.  207}. 
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Figure  IV. 1.  Example  of  an  Instance  Value  as  the 
Intersection  Between  an  Object  and 
a  Valueset 


Following  this  approach  we  can  view  the  abstract  model  as  con¬ 
sisting  of  objects  and  selected  properties  related  to  them, 
where  each  single  property  is  composed  of  a  certain  name  and  a 
specific  value  from  the  predefined  domain.  Although  one 
property  may  take  different  values,  at  any  instance  it  can  be 
considered  as  a  pair  containing  a  single  name  and  a  single 
value.  This  will  be  discussed  in  more  detail  in  Section  B  of 


this  chapter.  So  in  short,  we  can  write  as  follows: 


objectj^  (pair^  ,pair2  /  •  •  •  ,pair^)  . 

The  basic  operations  performecj  on  our  simple  database  are: 
create 
insert 
modify 
retrieve 

test  for  membership 

where  briefly  described: 

create — installs  a  new  database; 

insert--adds  a  new  object  to  the  database; 

modif y--changes  a  certain  object  by  altering  one  of  its 
properties ; 

retrieve — retrieves  an  object  identified  by  its  particular 
properties  from  the  database; 

test  for  membership--returiis  a  boolean  value  depending  on 
the  fact  that  a  particular  object  does  or  does  not 
belong  to  the  database. 

For  futher  information  the  reader  is  directed  to  the  specifica¬ 
tion  part  of  this  thesis  where  the  entire  operations  are  defined 
in  much  more  detail. 

As  already  indicated  in  the  previous  chapter,  we  adopt  the 
following  view:  whenever  talking  about  objects  and  their 
properties  we  actually  deal  with  primitives  of  the  real  world 
which  are  neither  easy  to  handle  nor  can  they  be  stored  in  a 
machine.  To  be  more  precise,  in  constructing  a  model  we  only 
work  with  a  representation  of  the  objects  and  properties  but 
not  with  the  primitives  themselves.  In  doing  so,  the  portion 
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of  the  real  world  our  model  tries  to  catch  becomes  manageable. 
For  example,  although  we  can  not  put  the  object  STUDENT  into 
a  database,  it  is  no  problem  to  store  the  characterstring 
'STUDENT'  as  a  conceptual  representation  of  this  object.  The 
same  is  true  for  properties.  Since  there  is  no  way  to  store, 
for  example,  15  YEARS,  we  instead  extract  the  essential  infor¬ 
mation  {'15'  in  this  case)  which  is  more  convenient. 

Furthermore,  there  are  some  restrictions  to  be  taken  into 
consideration.  For  instance,  the  programmer  should  not  be 
allowed  to  insert  data  that  does  not  belong  to  the  valueset  of 
the  specified  property,  nor  modify  a  non  present  value.  Such 
cases  have  to  be  covered  by  a  special  error  handling  routine. 

B.  DEFINING  OBJECTS  AND  THEIR  PROPERTIES 

One  approach  to  defining  an  object  in  terms  of  mathematical 
notation  can  be  found  in  Hsiao  [Ref.  14:p.  67].  Although  Hsiao 
uses  a  different  terminology,  the  proposed  concept  is  as 
simple  as  it  is  clear: 

Let  A  be  a  set  of  'attributes'  and  V  be  a  set  of  'values. ' 

Then  a  'record'  R  is  a  subset  of  the  Cartesian  product 
A  < V  in  which  each  attribute  has  one  and  only  one  value. 

R  can  therefore  be  considered  as  a  set  of  ordered  pairs, 
or  in  short  notation, 

R  =  [ (attribute, value) .,..., (attribute, value)  ]. 

1  n 

The  meaning  of  this  equation  is  evident,  however  it  does  not 
necessarily  ensure  that  a  certain  value  will  only  be  attached 
to  an  attribute  for  which  it  is  explicitly  defined  in  the 
corresponding  domain.  Thus,  because  our  methodology  is  supposed 
to  be  strictly  formal,  the  given  equation  can  not  simply  be 


translated  by  just  changing  terms.  But  we  can  adopt  the  basic 
idea. 


The  technique  we  apply  must  prevent  us  from  mistakenly 
combining  terms  that  are  not  defined  for  each  other,  and  the 
way  we  described  our  properties  supports  this.  Since  a  property 
is  composed  of  a  pair  containing  its  name  and  the  appropriate 
set  of  values  which  specifies  all  the  legal  values  for  this 
particular  property,  only  combinations  between  members  of  this 
pair  are  possible.  At  each  instance  such  a  property  identified 
by  a  certain  name,  may  take  any  single  value  from  the  corres¬ 
ponding  domain,  thus  representing  one  specific  'snapshot' 
lying  within  the  range  of  feasible  combinations.  The  following 
example  illustrates  our  intentions. 
property  1; 

name :  ' age ' 

set  of  values  (domain);  ' 10 ' , ' 11 ' , ' 12 ' , ' 13  '  ,  '  14  '  , 

'  15'  . 

property  2 ; 

name;  'city' 

set  of  values  (domain);  'Monterey',  'San  Diego', 

'Los  Angeles',  'San  Jose'. 

Legal  combinations  representing  different  instances  of  the 
given  properties  would  be; 

'age' , 'll' 

'age' , '14 ' 

'city' , 'Monterey' 

'city',  'San  Diego' 


however,  combinations  like: 

'age', 'Los  Angeles' 
or  ' city ' , ' 11 ' 
are  not  possible. 

Thus,  we  have  to  attack  the  problem  in  two  successive  steps 
We  start  with  a  particular  property  name  out  of  the  set  of 
all  specified  names  N  and  with  as  the  corresponding  value- 
set  out  of  the  set  of  given  valuesets  V.  We  then  can  define 
a  property  in  a  similar  way  as  described  above  as  the  Cartesian 
product  X  where  i>  =  l. 

This  ensures  that  a  property  won't  have  other  values  than 
those  explicitly  stated  in  its  domain,  where  at  any  instance 
each  property  name  has  one  and  only  one  corresponding  value. 
Having  generally  defined  the  property  P  =  X  V^,  i>=l,  we 
now  can  easily  describe  an  object  as  a  sequence  of  one  or  more 
property  instances  P' 

0  =  (P'l . P'm^- 

Properties  by  themselves  do  not  make  much  sense  in  a  database, 
since  it  is  the  object  we  are  interested  in.  But  on  the  other 
hand,  objects  are  made  out  of  distinct  property  instances,  and 
so  both  the  object  and  its  describing  property  instances  repre¬ 
sent  the  primitives  in  our  database.  Following  a  top-down  or 
'from  the  simple  towards  the  more  complex'  strategy  in 
developing  a  specification  for  the  abstract  database,  the 
procedure  of  creating  an  object  is  illustrated  in  the  next 
example . 


An  instance  of  an  object  0^  can  then  be  described  by  a  sequence 
of  properties  P'  which  themselves  contain  a  name  and  a  particu¬ 
lar  value,  or  in  other  words,  it  represents  several  'snapshots' 
of  the  properties  P.  The  previously  given  description  of  an 
object  should  be  clear  by  now; 


0  =  (P',  ,P'_,  .  .  .  ,P'  )  . 
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A  property  name  will  be  mapped  together  with  any  of  the  values 
assigned  to  the  domain  of  the  corresponding  property,  but  will 
be  restricted  to  only  one  value  at  a  time  when  defining  a 
certain  object,  although  a  single  property  name  can  take  differ¬ 
ent  values  for  different  objects. 


This  probably  becomes  more  obvious  when  looking  at  a 
graphical  example,  following  in  some  sense  the  approach  to  a 
formal  development  for  data  structured  in  accordance  with  the 
different  database  models  given  by  Hull  [Ref.  16:pp.  518-528]. 

Notation:  Let  N  be  the  distinguished  set  of  property  names 

and  let  V  be  a  set  of  valuesets  such  that  N  n  V  =  0  (no  common 
elements) . 

Definition:  Then  P  is  the  set  of  all  properties,  where  F 

maps  to  each  subset  of  P  a  property  name  and  a  valueset 
such  that  the  following  conditions  apply  (Figure  IV. 2): 


N  (set  of  property  names) 


Figure  IV. 2.  Creation  of  Properties 


F{N^,V^)— >P^; 
g  :  P  .  —  >V  .  ; 

h:  Pj — >Nj; 

F(g(P^) ,h(P^) )  =  P^; 

Restricting  these  mappings  in  such  a  way  that  values  of  a  cer¬ 
tain  property  can  only  be  transferred  from  the  valueset  (domain) 
which  is  defined  for  this  property  type,  properties  consisting 
of  different  name/value  pairs  can  be  created. 

Applying  d  =  <P,F>  then  gives  us  the  tool  to  describe  the 
first  part  of  the  primitives,  the  properties.  Next  we  need  to 
define  the  remaining  part,  the  objects.  To  achieve  this,  let 
0  be  a  set  of  objects,  where  I  maps  certain  pairs  (N.,V.  )  t  P-, 

XXX  X 

for  l<  =  i,x,  to  elements  of  0  such  that  I(Nj^,  )  ^  I  (N^  ,  )  for 
every  two  belonging  to  the  same  object.  Then  s  =  <<P,F>,I 

=  <d,I>  can  be  used  to  describe  any  object  0^  by  applying  I 
one  or  more  times  to  different  &  P^.  The  following 

conditions  are  true  for  this  mapping  (Figure  IV. 3): 

1(1(0^))  =  0^; 

The  restrictions  added  are  indeed  necessary  in  order  to  pre¬ 
vent  illegal  operations  on  the  sets,  which  otherwise  would  be 
possible.  Both  methods  discussed  above  lead  to  the  same  re¬ 
sult,  and  it  was  the  goal  of  this  section  to  give  the  reader 
an  understanding  of  our  strategy  in  defining  objects  and  their 


properties.  Although  this  strategy  may  appear  somewhat 


0  (set  of  objects)  P  (set  of  properties) 


Figure  IV. 3.  Creation  of  Objects 

complex,  it  represents  a  serious  attempt  to  handle  the  data¬ 
base  primitives  in  a  consistent  way  while  staying  as  formal  as 
possible.  And  before  continuing  with  the  next  section  which 
deals  with  the  creation  of  object  classes,  a  final  note  has  to 
be  attached;  To  distinguish  between  different  objects  it  is 
necessary  to  include  at  least  one  name/value  pair  that  uniquely 
identifies  each  object.  This  identifier  is  called  the  'key.' 

If  there  is  no  such  key  available  then  there  might  be  the  case 
where  it  is  impossible  to  distinguish  one  object  from  another. 

Objects  that  are  structured  in  a  similar  way,  which  means 
they  are  defined  by  the  same  property  names  appearing  in  the 
same  order,  can  be  grouped  together  to  form  a  class.  Such  a 
class  may  then  be  identified  by  the  kind  of  its  property  names 


and  the  order  they  are  arranged  in.  However,  this  is  a  tedi¬ 
ous  method.  It  is  therefore  more  realistic  to  introduce  a 
classname  as  identifier  to  distinguish  between  different  classes 

In  either  case,  the  kind  of  identifier  is  considered  to  be 
an  implementation  issue  and  will  be  ignored  at  this  point. 

C.  OBJECTCLASSES 

A  convenient  way  to  handle  a  large  number  of  objects  is  by 
grouping  them  together.  This  can  be  done  with  all  objects  that 
are  related  to  each  other  in  a  logical  sense.  These  sorted 
objects  then  form  a  class  or  subclass  of  objects,  where  each 
class  has  its  own  characteristics  that  distinguish  it  from 
another.  Since  objects  are  composed  of  several  name/value 
pairs,  the  presence  of  those  pairs  and  the  order  in  which  they 
appear  is  the  criterion  for  associating  any  given  object  with 
a  particular  class.  A  graphical  example  of  a  subclass  is  pre¬ 
sented  in  Figure  IV. 4.  The  subclass  can  be  considered  as  a 
two-dimensional  scheme  with  the  objects  arranged  in  horizontal 
order  and  the  properties  as  different  columns.  From  this  repre¬ 
sentation  it  becomes  obvious  that,  if  a  certain  property  is 
not  contained  in  the  subclass,  none  of  the  objects  of  that  sub¬ 
class  can  have  this  property  at  any  instance.  In  mathematical 
notation  this  could  be  expressed  as: 

{object^6Subclass^)/^(pair^€Objectj^)  — >  (pair^ssubclass^) 

where  pair  represents  an  instance  of  property  containing 
z  z 

name^  and  one  single  value  from  the  corresponding  domain 


defined  for  property  . 


property^  . property^^ 

objectj^ 


object 

n 

Figure  IV. 4.  Objects  Forming  a  Subclass 

In  the  same  way  that  objects  can  be  grouped  together  to  form  a 
subclass,  several  subclasses  again  can  be  arranged  to  form  an 
objectclass.  Both  are  achieved  by  means  of  'generalization,' 
a  technique  discussed  in  the  next  section. 

An  objectclass  can  be  considered  as  a  three-dimensional 
scheme  consisting  of  'layers'  of  subclasses  as  shown  in  Figure 
IV. 4.  To  create  this  figure,  turn  the  subclass  in  such  a  way 
that  it  fits  into  the  horizontal  plane,  and  then  install  each 
on  top  of  the  others.  Using  this  method,  the  arrangement  be¬ 
comes  more  evident  (Figure  IV. 5).  So  a  subclass  equals  a  cer¬ 
tain  level  of  this  block  whose  shape  depends  on  the  number  of 
properties,  objects,  and  subclasses  being  applied.  The  entirety 
of  all  levels  or  subclasses  forms  the  objectclass.  Objects 
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which  do  not  belong  to  one  subclass  but  have  to  be  present 
because  they  are  contained  in  another,  are  considered  as  just 
being  left  blank  in  all  the  subclasses  in  which  they  are  not 
represented . 


Figure  IV. 5.  Subclasses  Forming  an  Objectclass 

If  a  certain  property  is  not  containted  in  the  objectclass, 
none  of  the  objects  belonging  to  that  class  can  have  this 
property  at  any  instance.  In  mathematical  notation  this  can 
be  expressed  as: 

(pair  6<±) ject  ) ri(object  -:subclass  )/^(suLclass  ^objectclass  ) 

Z  X  X  y  y  n 

- >  (pair^-:objectclass^) 

v^here,  again  pair  represents  an  instance  of  property  con- 

z  z 

taining  name^  and  a  single  value  from  the  corresponding  domain 
of  property 2,-  So  in  searching  for  a  particular  name/value 
pair,  first  the  objectclass  can  be  checked  for  the  matching 
property  name,  then  if  positive,  the  subclasses  have  to  be 


checked,  and  finally  the  object  that  responds  to  the  require¬ 
ments  will  be  localized-  By  this  means  a  search  can  be  limited 
to  those  objects  most  likely  to  contain  the  requested  name/ 
value  pair. 

1 .  Generalization 

Generalization  is  defined  as  " .  .  .an  abstraction 
which  enables  a  class  of  individual  objects  to  be  thought  of 
generically  as  a  single  named  object"  [Ref.  17 :p.  107].  Re¬ 
placing  the  term  'named  object'  by  the  new  term  'subclass'  this 
technique  provides  a  way  for  conveniently  describing  how  sub¬ 
classes  and  objectclasses  can  be  constructed.  This  is  true 
because,  on  the  next  higher  level,  subclasses  themselves  by 
abstraction  build  a  generalized  new  'object, '  too,  the  object- 
class  (Figure  IV. 6a). 


(objectclass) 


(subclasses! 


(objects) 


Figure  IV. 6a.  An  Example  of  Generalization 


By  generalization,  which  can  be  considered  as  a  bottom-up 
technique,  it  is  possible  to  create  the  abstraction  necessary 
for  the  abstract  database  (Figure  IV. 6b). 


generalization 


class 


object^ 
ob ject2 


object 


Figure  IV. 6b.  Creating  a  Class  from  Objects  by  Generalization 


This  bottom-up  approach,  if  all  the  objects  belonging  to  one 
class  are  included,  must  then  logically  be  reversible  in  such 
a  way  that  a  given  class  would  lead  to  every  single  object  being 
defined  by  that  class.  For  example,  the  class  'mammals' 
naturally  contains  also  the  object  'horse,'  and  horses  belong 
to  the  class  of  mammals. 

2 .  Aggregation 

In  order  to  define  the  instance  properties  of  an 
object,  those  properties  must  be  determined  for  every  object. 
This  can  be  achieved  by  the  technique  of  'aggregation'  by  which 
different  name/value  pairs  are  grouped  together  so  that  they 
can  be  used  to  describe  an  object  (Figure  IV. 7). 


Figure  IV. 7.  Creating  an  Object  from  'pairs'  by  Aggregation 


Although  this  method  looks  like  a  refinement  of  the  object, 
aggregation  in  fact  works  the  opposite  way  (bottom-up)  and 
cannot  be  treated  as  an  inversion  of  the  generalization. 
Furthermore,  aggregation  is  not  automatically  reversible, 
which  means  an  object  may  have  certain  name/value  pairs,  how¬ 
ever  these  pairs  do  not  necessarily  define  this  specific  ob¬ 
ject  in  an  unique  way.  For  example,  although  a  person  can  be 
described  by  the  name/value  pair  ( ' age ' , ' 10 ' ) ,  this  particular 
pair  need  not  necessarily  refer  to  a  person.  So  in  contrast 
to  the  generalization,  where  an  exhaustive  installation  of 
objects  belonging  to  one  class  would  guarantee  reversibility, 
with  aggregation  this  depends  on  the  way  an  object  is  viewed. 

Using  the  method  of  generalization  and  aggregation  we  are 
able  to  draw  a  picture  of  the  general  structure  of  the  data¬ 
base  (Figure  IV. 8).  This  drawing  also  clearly  demonstrates 
that  each  instance  property  of  any  object  belonging  to  a  cer¬ 
tain  class,  must  itself  belong  to  that  class: 

[ ( (name/value  pair) tobject) tsubclass] tobjectclass 

D.  THE  SPECIFICATION  LANGUAGE 

1 .  Grammar 

First  developed  by  Yurchak  (Ref.  2]  and  in  a  few  parts 
modified  by  Hunter  [Ref.  3] ,  the  grammar  used  for  the  specifi¬ 
cation  language  will  be  left  unchanged  to  preserve  the  meaning 
of  AM  as  the  machine  as  originally  designed.  The  grammar  for 
the  specification  language  as  found  in  Appendix  A  is  exactly 


Figure  IV. 8.  General  Structure  of  the  Database 

the  same  as  used  by  Hunter.  The  following  description  of  the 
grammar  and,  in  the  next  section,  the  preprocessor,  represents 
an  extract  of  Hunter's  respectively  Yurchak's  work.  It  was 
inserted  to  give  the  reader  some  understanding  of  the  under¬ 
lying  fundamentals. 

The  selected  grammar  is  similar  to  examples  found  in  the 
literature,  but  the  specification  language  includes  some  feature 
usually  reserved  to  programming  languages.  A  specification 
with  modules  called  'spec'  is  constructed  first  using  this 
language  while  by  means  of  the  'extension'  operator  it  is 
possible  to  combine  the  specs  in  a  hierarchical  order.  Each 
spec  may  introduce  zero  or  more  new  'sorts,'  'operators'  and/ 
or  'axioms. '  A  'sort'  can  be  considered  as  a  data  type  and 
forms  an  object  set  from  which  the  operands  are  selected  for 
the  operators.  The  elements  in  a  sort  are  created  from  the 
listed  'operations.'  VJhenever  feasible,  one  or  more  constants 
are  declared  in  the  beginning  to  provide  a  basis  for  other 


elements.  For  example,  the  constant  zeronatO  would  be  such  a 
basis  for  generating  other  elements  in  spec  natural. 


Sorts  introduced  in  a  spec  may  also  be  added  to  an 
existing  spec  through  'extension'  of  the  spec(s)  that  will  be 
taken  as  the  basis,  or  they  may  form  the  primitives  for  a  new 
'branch'  of  the  hierarchy.  Extension  provides  the  only  means 
of  relating  the  sorts  and  operators  from  different  specs  so 
that  the  newly  declarated  operators  refer  to  both  the  new  sort 
as  well  as  to  any  sort  from  the  extension. 

Parameterized  specifications  are  permitted  but  their 
use  is  minimized,  as  their  properties  are  not  well  understood. 
Spec  string  is  one  representative  of  this  type  of  specification. 

The  semantics  and  the  overall  structure  of  the  specifi¬ 
cation  must  obey  certain  rules.  All  symbols  must  be  unique. 

No  symbol  may  be  used  unless  it  has  first  appeared  as  the  name 
of  a  spec,  in  a  sort  definition,  or  to  the  left  of  a  colon  in 
an  operator  declaration.  Following  this  rule  guarantees  that 
at  no  time  the  properties  of  the  object  inferred  by  the  name 
are  ambiguous.  Thus,  the  structure  of  the  specification  is 
much  like  a  Pascal  program,  but  more  restrictive.  In  short, 
there  are  no  self  referential  specs,  and  no  use  of  a  spec  is 
possible  before  it  has  been  defined. 

The  specification  language  classifies  all  operators 
into  one  of  three  categories:  'primitive,'  'derived,'  and 
'hidden. ' 

'Primitive'  operators  are  those  which  must  be  imple¬ 
mented  to  provide  a  full  instantiation  of  the  spec 
and  form  the  basis  of  the  resource  description. 
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Although  not  every  primitive  operation  needs  to  be 
directly  implemented,  the  full  functionality  of  each 
primitive  operator  must  be  present.  It  is  up  to  the 
implementor  whether  he  likes  to  exclude  some  of 
the  primitives  or  some  of  the  operators  described 
by  those  primitives,  as  long  as  full  functionality 
remains  available  from  either  set  of  operators. 

'Derived'  operators  are  those  which  can  be  derived 
from  the  primitives.  The  implementor  may  ignore 
these  operations  because  their  function  always  can 
be  performed  by  the  composition  of  primitives.  Their 
inclusion  is  merely  a  matter  of  convenience.  An 
example  would  be  the  derived  operators  'or'  and 
'implies'  in  the  spec  boolean,  whose  functions  are 
entirely  covered  by  the  primitive  operators  'not' 
and  ' and. ' 

'Hidden'  operators  are  those  to  which  the  programmer 
has  no  access.  They  represent  abstractions  of  the 
machine  required  to  express  a  certain  semantics.  It 
might  be  convenient  to  have  them  in  one  case,  while 
in  another  they  may  be  essential  to  the  semantic 
description.  A  typical  example  for  a  hidden  operator 
is  the  READFRONT  operation  in  the  specification  of  a 
queue,  as  discussed  in  Chapter  II.  Here,  this 
operator  is  required  to  build  meaningful  axioms. 

The  'if-then'  and  ' if-then-else '  constructs  are  used  to  build 
conditional  axioms.  Their  function  follows  the  same  princi¬ 
ples  as  it  does  in  other  languages,  for  instance,  in  Pascal. 
This  means,  when  the  evaluated  'boolean  expression'  is  true, 
the  'then'  part  of  the  statement  applies,  otherwise  the  'else 
part.  The  'boolean  expression,'  finally  is  defined  as 


expression  meta_relop  expression 

where  the  term  'meta_relop'  stands  for  the  metalanguage  sym¬ 
bols  "="  (equality  relation)  or  "!="  (inequality  relation), 
and  is  used  to  decide  about  the  truth  of  the  given  boolean 


expression . 


So  in  some  sense,  the  underlying  grammar  for  our  speci¬ 


fication  language  is  similar  to  the  ones  used  for  compiler 
compilers.  In  general,  the  application  of  a  metalanguage 
provides  an  important  tool  to  formulate  various  aspects  of  the 
developing  design,  since  it  can  be  used  as  a  description  for 
another  language.  Simple  technical  terms,  such  as  'if,'  'then,' 
'else'  or  'endif  were  introduced  to  make  our  intentions  more 
clear  in  both  the  grammar  and  specification.  In  order  to  dis¬ 
tinguish  between  the  metalanguage  terminology  and  the  regular 
language,  metanames  always  are  boldface.  A  typical  represen¬ 
tative  for  such  a  metalanguage  is  the  BNF  (Backus-Naur  Form) 
which  serves  as  a  notation  for  describing  the  syntax  of  pro¬ 
gramming  languages  using  ordinary  technical  English,  supplemented 
by  conventional  mathematics. 

2 .  The  Macro  Preprocessor 

The  main  purpose  of  the  macro  preprocessor  is  to  con¬ 
dense  the  amount  of  language  wherever  repetitions  would  swell 
the  volume  of  specifications.  This  technique  also  improves 
readability  because  those  parts  of  a  specification  sharing  a 
common  macro  definition,  can  easily  be  identified.  And  since 
it  is  based  on  the  same  principle,  understanding  one  macro 
definition  is  the  starting  point  for  understanding  all  of  them. 

As  with  the  grammar,  the  idea  of  the  preprocessor  was 
originally  introduced  by  Yurchak  when  he  designed  AM  (version 
1.0).  This  convenient  technique  has  been  continued  by  Hunter 
in  developing  AM  (version  2.0),  and  it  will  also  be  used  for 


the  abstract  database.  The  fundamental  theory  remains  un¬ 
changed.  In  the  following  section  a  description  of  the  pre¬ 
processor  is  given  as  it  was  defined  by  Yurchak  [Ref.  2]  and 
adopted  by  Hunter  [Ref.  3] . 

The  basic  form  of  a  macro  definition  is 


replace  "text  ..."  with  "other  text  ..." 

Since  the  grammar  of  our  specification  language  does  not  re¬ 
quire  quotes,  they  are  used  as  delimiters  for  definition  and 
equivalence  strings.  A  macro  with  arguments  appears  like 

replace  (A,B,...,Z)  "text  .  .  ."  with  "other  text  .  . 

where  the  formal  parameters  must  be  capital  letters.  An  upper 
case  letter  always  denotes  a  formal  parameter  to  a  macro, 
since  there  are  no  uppercase  letters  allowed  within  the  spec 
itself.  Thus,  for  the  definition 


replace  (S) 

"typeof(S);" 

with 

"types : — >type; 
atomofS:  val — >S; 
valofS:  S — >val; 

then  the  string 


typeof (bool) ; 
would  be  replaced  by 


typebool : -->type ; 
atomofbool:  val — >bool; 
valofbool :bool — >val ; 


wherever  it  appeared.  The  utility  of  the  macro  becomes  obvious 
when  we  look,  for  example,  at  the  fetch  and  store  operators, 
used  to  retrieve  and  store  values  of  any  type  from/in  primary 
memory.  All  AM  data  types  map  into  a  common  sort  called  'val,' 
which  is  returned  from  or  passed  to  memory  by  these  operators. 
In  order  to  avoid  the  need  for  describing  big  numbers  of  vir¬ 
tually  identical  mapping  functions,  by  means  of  macro  defini¬ 
tions  it  is  possible  to  describe  the  first  data  type  and  then 
just  list  all  the  others.  This  feature  clearly  simplifies  the 
specification  task. 

Macro  definitions  are  also  excellent  for  expressing 
certain  properties  of  operators  such  as  commutativity,  trans¬ 
itivity,  etc.,  which  are  used  throughout  a  specification. 
Instead  of  writing  out  the  associated  axioms  repeatedly,  which 
could  prove  to  be  tedious  the  definition  of  macros  with  appro¬ 
priate  parameters  permits  a  more  readable  and  explicit  expres¬ 
sion  of  these  properties.  The  following  example  gives  an 
illustration : 

equint:  int,int — >bool; 

If  the  arguments  are  equivalent,  then  the  operation  should  re¬ 
turn  true ( ) ,  otherTtfise  false ().  In  order  to  express  eqint 
as  the  equivalence  relation  on  objects  of  type  int,  three 
axioms  are  needed: 

equint  (i,i)  =  trueO; 

equint(i,j)  =  equint(j,i); 

implies (and (equint ( i , j ) , equint ( j , k) ) , equint ( i , k) ) 

=  true ( ) ; 


This  by  itself  would  be  no  reason  for  concern,  but  there  can 
be  a  variety  of  relations  like  this  within  a  specification, 
and  for  each  single  case  these  three  axioms  have  to  be  re¬ 
peated  in  some  way.  Macros  provide  the  adequate  solution, 
since  a  macro  defined  like 

replace (X, S) 

"equivrel  {X,S) ; " 

with 

"for  i  in  S 
X ( i , i )  =  true ( ) ; 
for  i , j  in  S 
X  ( i  ,  j  )  =  X  (  j  ,  i )  ; 
for  i,j,k  in  S 

implies (and(X {i, j)  ,X(j ,k) )  ,X(i,k) )  =  true ( ) ; 

enables  us  to  use  this  definition  as  a  template  in  which  equint 
just  has  to  be  inserted 

equivrel (equint , int)  ; 

thereby  transforming  equint  into  an  equivalence  relation  on 
int  in  one  step.  Note  that  we  are  not  required  to  explicitly 
specify  the  type  of  free  variables,  since  this  can  normally 
be  determined  by  context.  We  do  so  in  the  interest  of  clarity 
because  there  can  be  no  doubt  for  which  type  'equint'  is  an 
equivalence  relation. 


V.  THE  DESIGN 


Having  an  operating  AM  processor  available  that  already 
includes  the  control  and  primitive  data  type  operations  as 
well  as  the  visual  display  device,  the  next  step  towards  the 
goal  of  developing  a  fully  operational  machine  was  to  add  a 
database  resource  which  could  do  a  far  better  job  than  a 
conventional  file  handling  system.  With  the  design  of  the 
abstract  database,  now  a  model  had  to  be  created  that  was 
appropriate  for  manipulating  data  in  a  way  to  effectively  sup¬ 
port  the  programmer's  requirements.  Because  a  database  is  a 
complicated  and  complex  subject,  our  intentions  were  to  model 
a  resource  which  includes  only  the  fundamental  operations  as 
stated  in  the  earlier  chapters.  This  restriction  had  to  be 
introduced  in  order  to  keep  the  time  constraints  given  for  this 
thesis.  The  complete  specification  for  AM  is  presented  in 
Appendix  B. 

However,  one  note  of  caution  has  to  be  added  like  the  one 
originated  by  Hunter  [Ref.  3]  in  his  description  of  the  bit¬ 
mapped  display  system;  despite  our  best  efforts  to  be  thorough 
and  rigorous,  this  AM  specification  may  still  contain  some 
errors.  This  is  not  only  so  because  extending  a  program  written 
by  others  most  likely  supports  this  possibility,  but  first  of 
all  because  it  is  a  rather  difficult  matter  to  ensure  that  there 
is  no  ambiguity  in  the  axioms.  It  also  can  not  be  guaranteed 


that  every  portion  of  the  spec  is  complete  so  that  legal  but 
undesirable  implementations  would  not  be  permitted. 

A.  THE  DATABASE  CONCEPT 

In  contrast  to  the  graphics  part  of  AM,  the  database  once 
instajuied  by  the  application  programmer  is  fairly  limited  to 
manipulating  data  in  the  predefined  way.  Creativity  in  the 
sense  of  trying  and  improving  is  only  possible  during  the  con¬ 
ceptual  phase  which  always  preceeds  the  actual  installation. 
This  means  the  programmer  must  have  a  clear  concept  about  what 
to  describe  and  how  to  arrange  it  in  the  most  suitable  way 
before  the  implementation  finally  can  take  place.  A  database 
represents  a  number  of  data  being  arranged  in  accordance  with 
certain  characteristics  or  particular  relations  of  interest  to 
the  programmer.  The  main  question  to  be  answered  is  how  to 
abstract  a  database  to  its  fundamentals  so  that  a  programmer 
can  work  with  it.  Once  the  basic  elements  were  identified  as 
'objects'  and  the  'properties’  defining  them,  the  next  step 
was  to  develop  the  set  of  functions  controlling  the  database 
that  would  support  a  natural  way  of  thinking  about  the  intended 
operations.  In  order  to  remain  consistent,  even  the  'property' 
as  the  basic  component  of  an  object  had  further  to  be  split 
into  the  subparts  ' property_id '  and  'valueset.' 

This  approach  is  certainly  different  from  other  methodolo¬ 
gies  because  it  required  eleven  separate  specifications  just 
to  formally  define  the  database  and  its  abstract  elements. 
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Each  specification  must  be  considered  as  a  mandatory  step  on 
which  succeeding  specs  are  built.  And  each  spec  contributed 
in  an  important  way  to  defining  the  abstract  database  resource 
and  therefore  can  not  be  omitted.  This  number  of  specifications 
naturally  caused  some  problems  when  translating  every  single 
function,  in  many  cases  required  only  for  mathematical  reasons 
of  rigor  and  without  practical  usefulness  for  the  programmer, 
into  logical  sets  of  operations.  Although  these  operations  had 
to  be  built  in  and  are  now  available,  it  is  anticipated  that 
the  application  programmer  will  rather  restrict  himself  to  the 
more  useful  operations  typical  for  database  manipulations. 

From  the  programmer's  point  of  view,  it  is  not  of  interest 
to  retrieve  all  the  values  defined  for  a  certain  property  once 
the  domain  has  been  fixed.  He  more  likely  wants  to  determine 
the  name/value  pairs  associated  with  a  particular  object  or 
find  out  whether  one  or  more  objects  meet  a  given  condition. 

Due  to  the  underlying  method  objects  are  structured  this  can 
be  achieved  on  the  basis  of  list  functions  that  will  be  dis¬ 
cussed  in  some  detail  in  the  following  sections.  In  general, 
we  adopt  the  idea  that  a  database  can  be  considered  as  a  big 
list.  This  approach  was  finally  chosen  because  it  facilitates 
our  effort  to  describe  the  principles  of  the  abstract  database. 

A  standard  database  has  to  be  created  first  in  the  mind  of 
a  programmer,  then  drawn  on  a  piece  of  paper  and,  eventually, 
installed  on  the  computer.  This  sequence  represents  a  typical 
top-down  approach,  starting  with  the  overall  database. 


partitioning  it  into  different  classes  and  subclasses  and, 
finally,  assigning  objects  to  them.  This  approach  keeps  the 
programmer  at  a  very  low  level  of  abstraction,  where  the  com¬ 
puter  can  not  provide  much  assistance.  Adding,  for  example, 
a  new  object  would  require  us  to  first  specify  the  particular 
class  to  which  it  belongs.  It  would  definitely  ease  the  pro¬ 
grammer's  effort  when  he  could  work  on  a  higher  level  of 
abstraction  by  using  the  power  of  the  computing  resource  to 
insert  such  an  additional  object  without  caring  about  the 
specific  class  it  refers  to.  But  although  this  approach  has 
some  fascinating  aspects  it  was  not  developed  since  object- 
classes  are  characterized  by  the  kind  of  their  property  names, 
and  thus  have  to  be  specified  carefully.  The  probability  of 
erroneous  entries  seemed  too  high  to  adopt  this  concept  for 
our  research. 

As  stated  in  Chapter  III,  we  also  abandon  the  introduction 
of  a  data  definition  language  (DDL)  and  a  query  language  since, 
due  to  their  high  level,  a  great  deal  of  the  intended  abstrac¬ 
tion  would  be  taken  away.  This  becomes  quite  obvious  just  by 
the  fact  that  there  are  meanwhile  several,  non-compatible 
query  languages  established.  Because  our  goal  is  to  specify 
one  particular  part  of  a  database,  namely  the  interface  be¬ 
tween  the  conceptual  level  and  the  physical  level,  we  confine 
our  work  to  the  fundamental  principles  and  focus  exclusively 
on  the  essential  aspects  of  the  database.  For  the  interested 
reader  it  should  however  be  mentioned  that,  once  AM  is  completed, 


there  are  plans  for  the  near  future  to  develop  a  high-level 
language  for  AM,  too,  which  would  naturally  ease  the  workload 
of  the  prograitimer . 

We  now  take  a  more  detailed  look  at  the  issues  and  design 
of  both  the  data  abstractions  and  resource  abstractions. 

B.  ABSTRACT  DATABASE  DATA  TYPES 

In  this  section  we  develop  the  abstraction  of  the  database 
in  detail  along  with  all  the  data  types  needed  to  support  it. 
In  addition,  we  discuss  issues  concerning  the  design  and 
examine  how  the  specification  captures  the  properties  of  the 
abstraction. 

One  of  the  problems  encountered  while  writing  the  specs 
for  the  database  was,  that  in  contrast  to  the  previous  speci¬ 
fications  which  mostly  operate  on  single  data  types  called 

3 

'atoms,'  it  became  necessary  to  refer  to  the  set  theory  which 
enables  us  to  deal  with  single  atoms  as  well  as  with  strings 
of  atoms.  Since  a  database  generally  contains  composed  ele¬ 
ments  rather  than  simple  atoms,  the  'set'  seemed  to  be  the 
right  means  to  tackle  this  problem.  However,  a  set  does  not 
allow  the  same  element  to  be  represented  more  than  once,  which 
would  restrict  the  operations  in  an  unintended  way.  We  there¬ 
fore  preferred  to  adopt  the  characteristics  of  a  'list,'  where 
no  similar  limitations  exist.  This  required  the  installation 
of  an  additional  spec  list  that  permits  the  more  complicated 

3 

An  'atom'  represents  a  problem  solving  abstraction  and 
is  discussed  in  Chapter  VI. 


operations  on  strings.  The  list  will  be  described  in  detail 
in  Sections  C  and  D  of  this  chapter.  But  first  of  all,  we 
consider  the  basic  steps  of  how  to  abstract  the  database. 

1 .  Property-Identification  and  Value 

Each  instance  property  of  an  object  consists  of  a  name/ 
value  pair  which  from  now  on  will  be  referred  to  as  'property- 
value,'  containing  a  particular  property-identification  ('pid') 
and  a  single  value  ('val').  Spec  property_id  expresses  the 
properties  of  the  'pid'  data  type.  A  'pid'  can  be  a  string  of 
characters  that  qualifies  as  identifying  notation  for  a  data¬ 
base  property.  Different  'pids*  are  combined  to  a  set  forming 
the  'pidset'  data  type  which  can  be  considered  as  the  descrip¬ 
tion  of  the  domain  for  all  legal  names  properties  may  take. 

Spec  property_idset  models  this  domain.  The  operation  natur¬ 
ally  performed  on  this  data  type  is  creating  such  a  set,  start¬ 
ing  with  an  initial  'pid'  and  then  extending  it  by  repeated 
application  of  the  union  operator  with  the  option  of  using  the 
empty  set  as  well  as  the  universe  of  all  sets. 

The  values  associated  with  a  particular  property  are 
covered  by  spec  value.  This  spec  and  the  combination  of  its 
data  type  'val'  to  a  set,  the  new  data  type  'valset,'  whose 
properties  are  described  in  spec  valueset,  are  constructed  in 
exactly  the  same  way  as  the  specs  for  'pid'  and  'pidset.' 

All  values  which  may  be  meaningful  in  any  context  with  the 
determined  property  names  are  permitted.  For  example,  for 
the  'pid'  age  this  could  be  the  set  of  natural  numbers  from  1 
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to  100,  while  the  'pid'  address  might  require  a  set  of  charac- 
terstrings.  The  joint  operations  'unpidset'  or  'unvalset' 
ensure  that  there  are  no  redundancies  in  the  same  domain. 

But  it  is  the  programmer's  responsibility  to  create  the  size 
and  type  of  valuesets  that  fit  his  intentions  best.  In  this 
stage  it  would  be  possible  to  build  a  domain  containing  dif¬ 
ferent  types  of  data  which,  if  carelessly  applied  later,  could 
lead  to  an  erroneous  result. 

Both  the  'pidset'  and  'valset'  data  types  provide  a 
disjoint  operation,  and  a  test  for  membersnip  and  equivalence 
(relational  operators) .  Regarding  the  intersection  and  union 
operations,  provision  has  been  made  for  associativity  and 
commutativity . 

2 .  Property  and  Propertyvalue 

In  order  to  specify  a  property  in  its  entirety  we  need 
two  parts:  a  'pid*  that  describes  the  name  of  the  property, 
and  a  corresponding  'valset'  which  determines  the  domain  of  all 
the  values  this  particular  property  can  legally  have.  A 
property  is  represented  by  sort  'prop*  and  is  always  constructed 
from  the  ordered  pair  'pid'  and  'valset' 

prop  =  (pid , valset) . 

Spec  property  lists  this  data  type  and  the  possible  operations. 

To  reduce  a  property  to  one  of  its  two  fundamental 
elements,  the  operators  'getid'  and  'getvalset'  have  been 
introduced.  While  'getid'  returns  the  property  name  ('pid') 


getid:  prop  — >  pid, 

'getvalset'  returns  the  domain  ('valset')  of  the  property 
getvalset:  prop  — >  valset. 

These  two  operators  can  be  considered  as  reversion  of  the 
create  operator  'crprop.'  In  combination  with  the  empty  value- 
set  a  property  may  be  created  just  be  defining  a  certain  name, 
leaving  the  final  determination  of  the  corresponding  valueset 
unspecified  for  the  moment. 

Spec  propertyset  provides  the  data  type  for  different 
properties  associated  to  a  set  and  has  a  similar  structure  as 
spec  property_idset  or  spec  valueset.  But  since  every  property 
consists  of  the  ordered  pair  'pid'  and  'valset,'  by  the 
'getidset'  operator  all  the  'pids'  involved  and  specified  as 
'pidset'  can  be  retrieved 

getidset:  propset  — >  pidset. 

Defining  the  properties  for  the  database  in  this  way  was  the 
result  of  an  analytic  process  which  led  to  the  understanding 
that  a  property  indeed  is  composed  of  a  single  element  iden¬ 
tifying  its  type,  and  a  set  of  values  for  this  type.  Since 
the  sequence  is  important,  we  can  treat  a  property  as  an 
ordered  pair  of  single  elements.  But  following  this  definition, 
now  a  certain  property  does  not  make  much  sense  for  describing 
an  object,  because  it  can  not  be  used  as  a  characteristic 
criterion.  For  example. 


crprop:  ' grade ' , { ’ A ' , ' B ' , ' C ' 


'  D ' , ' E '  , ' F ' )  —  >  prop ; 


would  result  in  the  property  I ' grade ' , ( ' A' , ' B ' , ' C ' , ' D ' , ' E ' , ' F ' ) 
where  'grade'  equals  the  'pid'  and  ('A','B','C','D','E','F') 
the  'valset.'  Would  it  be  meaningful  to  describe  any  object 
by  this  property?  It  certainly  would  not,  because  this  is  a 
general  statement  about  the  property  'grade'  containing  all  the 
defined  values  a  grade  can  consist  of.  A  specific  object,  how¬ 
ever,  should  only  contain  a  specific  value  that  is  character¬ 
istic  for  it.  In  Chapter  IV  we  called  such  a  combination  a 
name/value  pair  or  an  instance  property.  Although  we  mentioned 
this  subject  before,  it  is  our  concern  to  illustrate  the  basic 
difference  between  a  property  and  a  particular  propertyvalue . 

Sort  ' pval '  in  spec  propertyvalue  defines  the  data  type 
to  resolve  the  problem  stated  in  the  previous  example.  Opera¬ 
tor  'crpval'  enables  us  to  create  the  required  instance  of  a 
property  that  itself  serves  as  the  basis  for  describing  any 
specific  object.  Referring  to  the  above  given  example 

crpval:  'grade', 'A'  — >  pval 

would  now  result  in  the  propertyvalue  ” ' grade ' , ' A ' "  which  then 
can  be  used  for  any  object  that  would  meet  this  condition. 
Besides  the  relational  operators  for  equality  and  ..lembership , 
as  for  all  composed  data  types,  there  are  operations  available 
which  return  either  the  first  element  of  the  ordered  pair, 
'getpid'  retrieves  the  'pid' 

getpid:  pval  — >  pid, 

or  the  second  element  which  can  be  retrieved  by  the  operator 
'getval'  returning  the  corresponding  value  of  data  type  'pval' 
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getval:  pval  — >  val . 


Since  objects  usually  are  described  by  more  than  just 
one  propertyvalue ,  spec  propertyvalueset  was  introduced.  With 
its  data  type  'pvalset'  it  is  possible  to  combine  different 
propertyvalues into  a  set.  This  is  the  final  step  on  our  way 
towards  defining  an  object  which  will  be  discussed  next.  In 
order  to  determine  the  different  properties  represented  in 
such  a  propertyvalueset,  the  property  names,  or  'pids,'  are 
of  major  interest.  They  can  be  retrieved  by  the  operator 
■getpidset'  which  accepts  any  'pvalset'  as  input  and  returns 
the  matching  'nidset' 

getpidset:  pvalset  — >  pidset. 

Due  to  the  fact  that  the  data  type  'pval'  consists 
of  the  ordered  pair  'pid'  and  'val,'  and  that  the  combination 
of  distinguished  'pvals'  forms  a  'pvalset,'  this  new  data  type 
is  also  composed  of  a  set  of  ordered  pairs  itself,  namely  the 
set  of  the  ordered  pairs  'pid'  and  'val.'  It  therefore  was 
necessary  to  add  two  distinguished  membership  operations,  one 
for  testing  whether  a  given  propertyvalue  is  contained  in  a 
particular  set  of  propertyvalues 

mempvalset:  pval, pvalset  — >  bool 

and  the  other  for  checking  if  a  given  propertyvalueset  belongs 
to  a  certain  propertyset  which  includes  information  about  the 
'pids'  involved  as  well  as  the  domains  for  the  corresponding 
values 


mempset:  pvalset ,propset  — >  bool. 


Again,  as  for  all  sets,  the  union  operator  'unpvalset' 
ensures  that  there  are  no  redundancies,  while  the  disjoint 
operator  'intpvalset'  would  retrieve  propertyvalues  contained 
in  both  sets  to  be  checked.  Furthermore,  the  standard  opera¬ 
tions  for  associativity  and  commutativity  have  been  included 
on  principle  in  this  more  mathematical  part  of  the  specification. 

3 .  Object  and  Qbjectclass 

As  mentioned  before,  the  essential  element  of  the  data¬ 
base  resource  is  the  object.  Each  of  the  previously  discussed 
specifications  represents  an  indispensable  portion  that  finally 
enables  us  to  express  the  data  type  'obj'  by  means  of  these 
more  elementary  data  types.  Its  properties  are  specified  in 
spec  object.  An  object  can  be  considered  just  as  a  particular 
set  of  propertyvalues,  each  containing  a  distinct  'pid'and  a 
'  val ' 

obj  =  pvalset  =  [  (pid,  val)  .  .  .  ,  (pid,  val)^]  . 

The  function  that  initiates  this  operation  is  called  'crobj.' 

The  kind  or  number  of  'pvals'  defining  an  object  is  of  no 
interest  for  us  at  this  point,  although  it  will  be  later.  So, 
theoretically,  any  combination  of  'pvals'  could  be  chosen  to 
build  up  an  object,  even  such  containing  the  same  'pid'  or 
'pval'  more  than  one  time  which  actually  would  be  meaningless. 

But  since  the  installation  of  a  database  is  always  preceded 
by  a  rather  precise  concept,  the  grouping  of  different  objects 


into  classes  then  should  eliminate  the  possibility  of  inci- 
dently  induced  redundancy  on  'pids.' 

The  reverse  operation  to  creating  an  object  is 
' getopvalset '  which  returns  the  entire  'pvalset'  defining  the 
object 

getopvalset:  obj  — >  pvalset 

while  the  operator  'getopidset'  retrieves  only  tni-  •  r  r«‘s:  *  rul¬ 
ing  set  of  'pids' 

getopidset:  obj  — >  pidset. 

In  genera],  the  type  of  properties  is  considered  more  important 
for  structuring  purposes,  as  this  criterion  forms  a  good  basis 
for  hierarchically  combining  related  objects  to  classes  (compare 
Chapter  IV,  Section  C) .  We  therefore  did  not,  as  the  reader 
might  have  expected,  introduce  an  analogous  operation  which 
would  return  all  the  values  of  a  given  object,  but  instead  pro¬ 
vided  the  operator  'getoval'  that  only  retrieves  one  single 
value  associated  with  one  particular  'pid'  of  the  object 

getoval:  obj, pid  — >  val . 

Provisions  are  also  made  for  an  equality  operator  'eqobj'  and 
a  membership  operator  'haspval'  which  checks  if  a  given  'pval' 
is  contained  in  a  certain  object. 

'Class'  is  the  data  type  that  represents  a  number  of 
objects  that  are  related  in  some  kind  to  each  other.  This  type 
has  been  discussed  in  some  detail  in  Chapter  IV.  Its  properties 


are  now  specified  in  spec  objectclass.  If  we  want  to  insert 
an  object  into  a  particular  class,  this  can  be  done  by  apply¬ 
ing  the  operator  ' insob j '  which  takes  a  class  fend  an  object 
and  returns  a  class  now  including  the  new  object.  We  must, 
however,  ensure  that  only  appropriate  objects,  which  means, 
with  matching  'pids,'  will  be  inserted.  This  problem  is  solved 
by  defining  an  operator  for  retrieving  the  'pidset'  of  a  class 
( ' getcpidset ' )  which  takes  a  class  as  input  and  returns  the 
corresponding  'pidset' 

getcpidset:  class  — >  pidset. 

Together  with  the  above  specified  operator  'getcpidset'  that 
accepts  an  object  as  input  and  returns  its  'pidset,'  the 
following  axiom  takes  care  of  this 

if  eqpidset (getcpidset (o) , getcpidset (c) )  =  true ( ) 
then 

insob j (c,o)  =  c; 
else  insobj(c,o)  =  undef; 
endif ; 

by  determining  whether  the  'pidsets'  of  the  object  to  be  in¬ 
serted  and  of  the  class  both  are  equal.  If  they  are,  then 
the  object  can  be  added,  if  not,  the  operation  becomes  unde¬ 
fined  and  the  object  can  not  be  added. 

A  similar  approach  was  taken  with  the  operator  ' delob j' 
for  the  deletion  of  a  selected  object  from  a  given  class.  It 
had  to  be  ensured  that  any  attempt  to  delete  from  a  class  some¬ 
thing  not  contained  in  it  was  discovered.  To  solve  this 


problem  the  membership  operator  'memclass'  used  in  the 
axiom 

9 

if  memclass (o , c)  =  true () 
then 

delobj (o,c)  =  c; 
else  delobj (o,c)  =  undef; 
endif ; 

to  first  check  if  the  selected  object  is  contained  in  the  given 
class.  This  certainly  is  not  a  very  efficient  way  of  doing 
the  deletion,  but  it  avoids  'blowing-up*  the  machine  by  an 
operation  that  can  not  be  handled. 

The  situation  where  a  class  is  itself  contained  in 
another  can  be  managed  by  the  relational  operator  'subclass.' 
This  provision  may  be  useful  when  the  hierarchical  structure 
is  of  importance.  In  connection  with  the  intersection  opera¬ 
tor  'intclass'  the  boolean  value  of  this  relation  can  easily 
be  determined: 

if  intclass  (Cj^ , C2  )  = 
then 

subclass (c^ =  true ( ) ; 
endif ; 

As  in  most  of  the  cases  the  'if-then'  part  of  this  axiom  could 
be  reversed  and  the  axiom  would  still  be  meaningful.  Here  it 
becomes  obvious  that  the  decision,  what  axioms  to  include  and 
which  to  omit  is  a  rather  difficult  matter  and  depends  widely 
on  the  view  of  the  designer.  But  since  there  is  no  sound 
recipe  for  how  to  proceed,  this  condition  may  be  a  source  for 


potential  errors  not  discovered  while  the  specification  is 
written. 

4 .  Database 

The  last  data  type,  'db, '  defined  in  spec  database 
represents  the  highest  level  and  operates  on  all  the  data  types 
previously  discussed.  So,  we  have  now  reached  our  goal  of 
combining  every  single  data  type  from  'pid'  up  to  'class.'  As 
the  reader  might  have  expected,  in  order  to  constrcut  a  data¬ 
base  one  or  more  objectclasses  must  be  available.  This  is  a 
mandatory  prerequisite  since  it  would  not  make  much  sense  to 
treat  a  couple  of  non-related  objects  like  a  database  that 
always  represents  a  particularly  structured  arrangement  of  data 
Operator  'crdb'  allows  us  to  create  a  database;  it  takes  a 
'class'  as  its  only  argument  and  returns  a  database.  A  'class' 
can  be  extended  to  any  required  size  by  the  union  operator 
defined  in  spec  objectclass.  This  method  not  only  avoids 
meaningless  redundancies  but  also  ensures  that  each  'pid'  con¬ 
tained  in  one  of  the  subordinated  classes  will  be  contained  in 
the  database,  too. 

Since  'db'  is  the  data  type  of  most  interest  for  the 
application  programmer,  all  the  fundamental  database  operations 
have  been  provided  in  this  specification.  For  example,  'getdb- 
pidset'  returns  the  set  of  'pids'  comprised  in  the  database, 
which  cannot  be  different  from  those  of  the  corresponding 
classes 

getdbpidset :  db  — >  pidset. 


This  is  expressed  by  the  following  axioms: 

getdbpidset (insclass (crdb (ci) )  ,02)  = 

unpidset (getcpidset (c^)  ,getcpidset (C2) ) ; 

which  states  that,  if  a  new  class  C2  is  inserted  into  a  data¬ 
base  consisting  of  the  class  c^^ ,  operator  'getdbpidset'  would 
return  the  set  of  'pids'  equal  to  the  joint  'pidsets'  of  c^ 
and  c^  as  determined  in  the  right  hand  part  of  the  equation. 

Operator  'retclass'  enables  us  to  retrieve  a  given  class 
from  the  database,  object  by  object 

retclass:  db, class  — >  pvalset. 

This  function  is  more  difficult  to  express  in  axiomatic  terms 

if  and ( 

and  ( 

(getopvalset (o)  =  pvs) , 

(memclass (o , c)  =  true ( ) ) 

)  , 

(memdb(c,d)  =  true ( ) ) 

)  =  trueO 
then 

intpvalset (retclass (d,c) , pvs)  =  pvs; 
endif ; 

Here  three  conditions  need  to  be  fulfilled  to  activate  the 
final  statement.  First,  a  given  object  o  must  have  a  particu¬ 
lar  'pvalset'  pvs,  second,  this  object  must  be  contained  in  a 
certain  class  c  which  itself  has  to  be  a  member  of  the  data¬ 
base  d.  Then  the  'pvalset'  pvs  must  also  be  contained  in  the 
database.  So  the  intersect  operation  of  all  the  'pvalsets' 


of  this  class  c  when  retrieved  from  the  database,  and  the 
particular  'pvalset'  pvs  must  finally  return  precisely  this 
pvs,  since  it  is  the  only  one  contained  in  both  the  class  and 
the  object. 

Provision  for  another  operator  has  been  made  that  re¬ 
trieves  an  object  whose  'pvalset'  is  matched  by  a  given  'pval' 
'retobj'  accepts  a  database  and  a  particular  'pval,'  and 
searches  the  database  for  objects  being  defined  by  this  'pval. 
Corresponding  objects  are  then  returned 

retobj:  db,pval  -->  ob j . 

A  queue  mechanism  operating  in  accordance  with  the  'first-in, 
first-out'  principle  manages  the  case  shou] d  more  than  a  singl 
object  be  retrieved.  The  axiom 

if  and ( 

and  ( 

haspval (pv,o) , 
memclass (o , c) 

)  , 

memdb (c , d) 

)  =  trueO 
then 

retobj {d , pv)  =  o ; 
endif ; 

states  that,  when  an  object  o  with  a  certain  'pval'  pv  is 
contained  in  a  class  c  which  itself  is  contained  in  the  data¬ 
base  d,  then,  when  objects  having  this  'pval'  are  searched  for 
by  operator  'retobj,'  these  objects  will  be  retrieved.  If 


there  is  only  one  object  meeting  condition  pv,  it  will  be 
presented  as  soon  as  it  is  discovered;  otherwise  a  niimber  of 
objects  will  be  put  on  the  queue  and  can  then  be  retrieved 
object  by  object.  Although  this  principle  is  simple,  it 
ensures  that  each  object  with  matching  conditions  can  be 
determined  and  is  available  to  the  programmer  at  the  end  of 
one  search. 

The  operator  'modobj'  allows  for  changing  a  'pval'  of 
a  given  object,  modiiying  it  thereby.  Three  arguments  are  re 
quired:  the  database,  the  object  itself  and  the  new  property 

value.  The  database  could  have  been  omitted  as  an  argument, 
but  it  guarantees  that  there  actually  is  a  certain  structure 
available.  The  hard  part  is  to  defect  any  case  for  which  the 
operation  might  not  be  defined,  for  example,  if  the  given 
object  does  not  belong  to  the  indie,  ted  database,  or  if  the 
replacing  'pval'  is  of  a  different  type  than  the  original 
or  its  value  not  defined  in  the  domain  of  the  associated 
property.  To  check  whether  all  these  premises  are  met,  five 
conditions  had  to  be  added  that  must  be  satisfied  in  order  to 
legally  carry  out  the  operation.  The  following  axiom  deals 
with  these  problems: 

if  and  ( 

and  ( 
and  ( 

and  { 

memprop ( pv , crprop ( pd , vs ) ) , 
mempidset (pd,getidset (prs) ) 


(getopidset (o)  =  getidset (prs) ) 


)  , 

memclass (o , c) 

)  , 

memdb (c , d) 

)  =  trueO 
then 

modobj (d,o,pv)  =  d; 
else  modob j (d , o , pv)  =  unde; 
endif ; 

Going  line  by  line  through  this  axiom,  it  is  stated  that 

1.  the  new  'pval'  pv  to  replace  the  present  one  has  to 

be  contained  in  the  property  created  from  the  'pid'  pd 
and  the  'valset'  vs,  or  in  other  words,  since  a  'oval' 
consists  of  a  certain  'pid'  and  a  single  'val,'  the 
'pids'  will  be  identical  while  the  'val'  of  pv  is 
contained  in  the  corresponding  'valset'; 

2.  'pid'  pd  must  be  a  member  of  'propset'  prs; 

3.  the  'pidset'  of  object  o  to  be  modified  must  be 
identical  with  the  'pidset*  contained  in  'propset'  prs; 

4.  object  o  must  be  contained  in  class  c; 

5.  class  c  must  be  a  member  of  database  d. 

If  all  these  conditions  are  met,  ' modob j (d , o , pv' '  is  defined 
and  the  operation  can  be  executed;  otherwise  it  would  be 
illegal  and  can  not  be  carried  out.  In  short,  this  axiom 
ensures  before  the  operator  can  be  applied,  that  the  new 
property value  may  be  inserted  because  the  entered  property_id 
is  actually  present  in  the  object  to  be  modified,  and  the  new 
value  is  defined  within  the  domain  of  the  associated  property. 
Thus,  one  instance  of  this  property  will  be  replaced  by  another 
instance  also  defined  for  the  particular  object. 
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The  remaining  operators  for  type  ' db '  are  similar  to 
the  ones  discussed  for  spec  objectclass  and  are  the  relational 
operator  for  membership  'memdb'  and  the  operator  'insclass' 
for  the  insertion  of  a  class,  respectively  'delclass'  for  its 
deletion.  As  analogously  described  before,  a  class  can  only 
be  deleted  if  it  is  contained  in  the  database;  ^his  is  expressed 
in  the  axiom 

if  memdb  (c,d)  =  trueO 
then 

delclass (d , c)  =  d ; 
else  delclass (d , c)  =  undef; 
end i f ; 

If  a  given  class  is  not  contained  in  the  database,  it  can  not 
be  deleted  and  the  operation  is  undefined.  With  the  insertion 
of  a  new  class  this  is  not  quite  as  simple: 

if  and f 

or  ( 

memdb  (Cj^ ,  d)  , 
memdb ( c^  ?  d ) 

)  , 

eqpidset (getcpidset (c^ )  , getcpi  dset ( c^  )  ) 

)  =  trueO 
then 

insclass (d , c^ )  =  undef; 
insclass (d , c^ )  =  undef; 
else  if  and ( 

and  ( 

memdb (c^ , d )  , 
not (memdb (c^ ,d) ) 


then  and) 


not (eqpidset (getcpidset  (c^)  , ge top id set  (C2 ) )  ) 
=  true  { ) 

( insclass (d , )  =  d) , 

(getdbptdset (d )  =  unpidset (getcpidset (c^ ) , 
getcpidset (C2) ) 

)  ; 

endif ; 

Here  the  axiom  defines  that  if  either  one  of  two  ob jectclasses 
already  a  part  of  the  database  d  and  both  have  the 
same  set  of  property_ids  '  eqpidset  (getcpidset  (c^^ ),  getcpidset  f  C2  )  ) 
then  there  is  no  way  of  inserting  any  of  these  classes  since 
they  are  a]  ready  represented.  If  one  of  the  classes  c^^  is  part 
of  the  database  while  the  other  (C2)  is  not  and  they  do  not  have 
the  same  set  of  property_ids ,  which  means  they  must  be  differ¬ 
ent  then  it  would  be  a  legal  operation  to  insert  the  one  not 
yet  contained.  The  property_idset  of  the  database  must  then 
be  extended  by  the  newly  added  'pids';  this  is  done  by  the 
joint  operator  'unpidset.' 

These  operations  define  spec  database  and  thereby  the 

fundamental  part  of  all  the  individual  specifications  required 

4 

for  mathematically  describing  the  database.  The  remaining 
portion  of  Appendix  B  represents  the  transition  towards  corres¬ 
ponding  operations  that  finally  can  be  translated  into  machine 
instructions . 


Algebraic  semantics  describes  what  has  to  be  done  rather 
than  how  to  do  it. 


C.  SPEC  PARAMETERIZATION 

The  characteristic  properties  of  a  list  allow  us  to  des- 
cribe  the  essential  database  operations  of  retrieve,  insert, 
modify,  and  delete  in  a  convenient  way.  Lists  not  only  provide 
a  clearly  structured  method  for  treating  strings  of  variable 
length  but  also  support  recursive  operations,  which  proves  to 
be  very  useful  for  searching  the  database.  It  is  the  purpose 
of  this  section  to  show  how  these  basic  operations  can  be 
managed  by  application  of  the  list  theory,  while  in  the  next 
section  we  describe  its  usefulness  for  our  particular  data¬ 
base  design. 

This,  however,  should  not  be  seen  as  the  attempt  to  narrow 
the  spectrum  of  possibilities  for  the  implementor  or  to  guide 
his  attention  into  one  specific  direction,  since  our  methodology 
focuses  on  representation  independence.  The  only  reason  for 
choosing  this  approach  is  that  it  provides  an  evident  way  to 
express  our  intentions. 

Since  the  contents  of  our  database  can  be  considered  as 
strings  rather  than  as  single  atoms,  it  was  necessary  to  make 
provision  for  this  by  introducing  the  additional  spec  list  with 
data  type  'elm,'  This  spec  is  a  representative  of  the  earlier 
mentioned  parameterized  specifications.  It  was  used  to  define 
the  special  list  operations  including  the  recursions  which 
offer  a  convenient  way  to  carry  out  searches.  Spec  list  allows 
the  treatment  of  all  previously  described  specifications  as  if 
they  were  of  type  'elm,'  simply  by  using  a  combination  of  spec 
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list  with  each  of  the  former  specs.  For  example,  by  applica¬ 
tion  of  the  first  discussed  spec  property_id  using  'list 
(property_id) , '  now  the  new  spec  pidlist  can  be  created  which 
enables  us  to  treat  the  initial  data  type  'pid'  as  'elm'  and 
the  operator  'eqpid'  as  'eqelm.'  This  procedure  has  the  advan¬ 
tage  that  we  can  stay  within  or  continue  with  the  logical 
structure  of  AM  specifications  as  they  were  developed  by  Yurchak 
[Ref.  2]  and  Hunter  [Ref.  3].  It  furthermore  is  a  contribution 
to  the  clarity  and  simp].icity  of  our  work  since  we  can  adopt  an 
available  technique. 

The  typical  list  operators  are  'nullst'  which  returns  an 
empty  list,  'firstelm'  which  returns  the  first  element  of  a 
given  list,  'firstlst'  which  retrieves  the  first  list  of  a 
given  list  of  lists,  and  'restlst'  which  returns  either  the 
remaining  elements  or  lists  of  a  given  list,  except  the  first 
one.  The  meaning  of  these  operators  is  expressed  in  several 
axioms 

firstelm (makelst (k) )  =  k; 

restlst (makelst (k) )  =  nullst; 

where  'makelst' is  itself  an  operator  which  takes  a  single 
element  and  returns  a  list  containing  this  element  as  its 
only  member 

makelst;  elm  — >  list. 

Should  a  given  list  be  empty,  so  that  there  is  no  first 
element  or  any  rest,  the  application  of  these  operators  leads 
to  an  undefined  result  by  the  corresponding  axioms. 


In  contrast  to  'makelst,'  the  operator  'makenewlst '  re¬ 
quires  a  list  as  an  input  and  returns  a  list  again.  By  this 
operator  it  then  is  possible  to  express  the  operation  'firstlst' 
in  the  following  axiom: 

firstlst (makenewlst (1) )  =  1; 

thus  operator  'makenewlst'  has  an  important  function  in  order 
to  indisputably  describe  the  meaning  of  operator  'firstlst.' 

In  fact,  it  sometimes  is  necessary  to  define  an  additional 
operator  just  for  the  purpose  of  expressing  an  already 
developed  operation  in  an  unambiguous  way. 

Operator  'catlst'  allows  us  to  concatenate  two  lists  into 
one  and  also  serves  as  a  significant  tool  for  illustrating  the 
meaning  of  the  previous  operations.  The  following  axioms  give 
an  example: 

firstelm(catlst (makelst (k) , 1) )  =  k; 
firstlst  (catlst  ( Ij^ ,  I2)  )  =  1  ; 
restlst (catlst ( 1^ , I2 ) )  =  I2' 

These  are  just  a  fev;  representative  axioms  dealing  with  the 
fundamental  list  operations.  Many  more  are  required  to  actually 
express  our  intentions.  They  can  be  found  in  Appendix  B. 

Again,  we  face  the  initially  encountered  problem  of  how  to  en¬ 
sure  that  we  did  not  miss  any  axiom  of  importance  which  possibly 
could  result  in  an  unwanted  operation.  So  there  is  indeed  no 
guarantee  that  our  perception  of  the  specified  resource  is 
precisely  what  the  specification  describes. 


Some  other,  not  necessarily  typical  list  operations  also 
had  to  be  introduced  for  the  particular  purpose  of  handling 
all  the  recently  defined  database  operations.  Because  these 
operators  are  more  complicated  they  will  be  discussed  in  some 
detail  in  the  following.  Each  of  them  requires  searching  the 
database  first  before  it  can  be  applied  or  successfully  ter¬ 
minated.  Consequently  an  iterating  process  was  needed  that 
could  do  the  job.  Due  to  its  simplicity  the  recursive^  ap¬ 
proach  was  chosen,  which  in  general  requires  a  termination 
condition  and  a  certain  pattern  that  reduces  the  overall  prob¬ 
lem  to  smaller,  solvable  subcases.  So,  what  we  actually 
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created  was  an  archetype  for  each  of  the  functions,  containing 
its  syntax  and  semantics,  where  the  recursive  definition  can 
be  considered  as  the  prototype  (compare  [Ref.  9]). 

i 

Operator  'deist'  is  a  function  that  accepts  two  lists  as 
an  input  and  returns  a  list.  The  first  list  is  the  one  to  be 
deleted  from  the  list  o^  lists  entered  as  the  second  argument 

e.g.,  delst[(l,),a  ,1.  ,1^)1  --  ■  (i  ,lj  '*1  =  list  */ 

Two  conditions  have  to  be  met  before  this  operator  can  legally 
be  applied:  The  list  from  which  we  delete  must  not  ue  empty, 
and  the  one  being  deleted  must  be  contained  in  it,  otherwise 
'deist'  becomes  undefined.  The  axiom 


Other  approaches,  like  repeatedly  applied  function  calls, 
could  also  do  the  job. 


if  or  ( 


eqlst (I2  f  nullst ( ) ) , 

*  not (memblst ( , I2 ) ) 

)  =  true ( ) 
then 

deist  ( / 12  )  =  undef; 
else  if  eqlst  ( 1  ^  ,  firstlst  (I2 )  )  =  falseO 
then 

makenewlst (catlst ( f irstlst { I2 ) , del st ( 1^ , restlst ( 1^ )  )  )  ) 
else  makenewlst (restlst (I2)  )  ; 
end if ; 

takes  care  of  these  cases.  The  next  step  then  is  to  find  the 
particular  list  1^  which  shall  be  erased.  The  only  way  to  do 
this  is  by  testing  list  after  list  of  I2  for  identity  with  1^^. 

If  the  one  being  examined  {' f irstlst ( I2 )' )  is  not  identical 
with  the  one  to  be  deleted  »  it  can  not  be  thrown  away  but 
instead  has  to  be  saved,  and  the  operation  must  be  repeated 
with  the  rest  of  list  l2*  This  is  achieved  by  the  'else-if  part 
of  the  axiom,  until  the  identity  is  finally  reached.  By  the 
'else'  part,  only  the  rest  of  list  I2  is  then  concatenated  to 
the  previous  portions  of  I2,  while  the  list  searched  for  will 
be  eliminated. 

Example : 
if  or( 

eqlst  [  (1^,1^^,!^)  ,  0  ]  , 

not  (memblst  Hlj^)  ,  Ij^,  1^,)  ] 

)  =  trueO 
then 

deist  [( 1,)  ,  f  1  , 1,  ,  1)  ]  =  undef; 


since  this  condition  does  not  hold  in  this  example,  the 
'else-if  part  will  be  checked: 

else  if  eqlst  [  (1,  )  ,  (1  )]  =  falseO 
then 

makenewlst  [catlst  (  ( 1  ),  deist  (( 1.)  ,( 1.  ,  1  )))]; 

a  b  b  c 

where  'deist'  initializes  the  repeated  application  of  the 
operation.  During  the  second  run  the  'else-if  condition 
becomes  true 

eqlst  [  (Ij^)  ,  (Ij^)  ]  =  trueO 

and  the  'else'  part  therefore  is  activated 

makenewlst (1  ); 

c 

this  leads  to  the  concatenation 

catlst (1,1) ; 

Si  c 

which  is  the  final  result  in  this  case. 

This  operation  still  retains  the  necessary  level  of  abstraction 
since  it  would  work  for  every  data  of  type  list.  The  structure 
of  the  database,  as  described  in  the  eleven  specifications  at 
the  begining  of  this  chapter,  supports  the  application  of  the 
list  theory.  This  issue  will  be  discussed  in  the  next  section. 

Operator  'getlst'  takes  a  list  1^  of  lists  and  a  particular 
list  I2  as  input  and  returns  the  list  corresponding  to  I2 

getlst  [  (1^^/I^2'^bl'^b2^  '  ^^bl-  ^  >  lj^2  list^  */ 


It  is  expressed  in  the  axiom 


if  or( 

eqlst  ( Ij^ ,  null  St  ( )  )  , 
eqlst ( I2  f  nul 1st ( ) ) 

)  =  trueO 
then 

getlst ( 1^ , I2 )  =  undef; 
else  if  eqlst ( firstlst ( 1, ), 1~ ) 


=  true  ( ) 


then 


getlst  ( ,  I2 )  =  firstlst  (restlst  (1^)  )  ; 
else  if  eqlst  ( f  irstlst  (restlst  ( )  )  ,  I2 )  =  true  ( ) 
then 

getlst ( 1^ , I2 )  =  f irstlst ( ) ; 
else  get 1st (restlst (restlst  (1^ ) )  ,12)  ; 
end if ; 


The  meaning  may  not  be  obvious  at  the  first  glance,  so  we  will 
explain  it.  The  underlying  principle  is  that  we  consider  a 
list  of  this  type  as  a  combination  of  several  pairs  of  lists. 
Thus,  entering  a  list  of  lists  '  ^a2  '  ^bl '  ^b2  ^  part 

(Ij^^)  of  such  a  pair  shall  result  in  retrieving  the  matching 
second  part  of  the  corresponding  pair  from  the  list  ( 1^^^ ,  1^2 ' 
^bl'^b2^'  Again,  precaution  has  to  be  taken  for  cases  where 
this  operation  can  not  be  performed.  For  example,  when  either 
of  the  lists  is  empty,  then  'getlst'  becomes  undefined.  The 
axiom  is  constructed  in  such  a  way  that  always  a  pair  of  lists 


from  the  first  list  is  checked  against  the  second  li  't  which 

itself  represents  only  one  half  of  a  pair.  Should  the  first 

part  of  the  list  ('firstlstd  ,,1  „ ,  1,  ,  1,  „ )  '  )  be  identical  with 

ai  a^  bl  b^ 

the  second  list  ,  then  the  matching  part  of  the  pair 

(  '  f  irstlst  ( restlst  (1^^  ,  1^2 ' 1)3]^ '  ^  ^  ^  will  be  returned  as  the 

result.  Should  the  second  part  of  such  a  pair  ('firstlst 

( restlst  (1^ ,  1^2  '  ^bl '  ^b2  ^  ^  identical  with  list  ( 

then  the  first  part  of  the  corresponding  pair  will  be  retrieved. 
If  no  match  occurs  the  'else'  condition  applies,  the  recursion 


is  activated  and  the  remaining  pairs  from  the  first  list  will 


be  checked  against  the  second  list.  So  in  case  was  not 

contained  at  all  in  1^^,  list  1^^  will  eventually  become  empty 

and,  since  it  is  not  possible  to  retrieve  a  part  of  a  pair  that 

does  not  exist  in  the  given  environment,  the  operation  must 

become  undefined  at  that  time.  This  is  exactly  what  will 

happen  by  means  of  the  termination  condition  for  the  recursion. 

Example : 

if  or( 

eqlst[ (Ial'^a2'^bl'^b2^  »  O 1  / 
eqlst  [  ( Ij^j^ )  ,  ( )  ] 

)  =  trueO 
then 

getlst[  (l^^,1^2'^bl''^b2^  '  ^^bl' ^  =  undef; 

since  this  condition  is  not  true,  the  'else-if'  part  will  be 
checked ; 

else  if  eqlst  [  (l^j^)  ,  (Ij^^)  ]  =  true  ( ) 
which  is  not  true  either,  so  the  next  'else-if'  condition  will 
be  checked: 

else  if  eqlst [( 1^2 ^ 1  “  true ( ) 
since  this  is  false,  the  'else'  part  is  activated 
else  getlst[  ]j^2^  '  (^51'  1  ' 

which  initializes  the  repeated  application  of  this  operator. 

In  the  second  run,  the  first  'else-if  condition  becomes  true 
else  if  eqlst  [( Ij^j^ ),{ Ij^j^ )  ]  =  true  () 
so  the  fol-lowing  statement  will  be  executed: 
then 

getlst  [  ( ,  lj^2^  '  ^^5]  )  1  =  lj^2' 

returning  1^2  which  is  the  list  that  corresponds  with  the 
second  argument  Ij^^  in  the  described  example. 


The  next  operator,  'sofirstlst'  (set  of  first  lists),  takes  a 
list  as  input  and  returns  a  list  or,  more  precisely,  it  requires 
a  list  of  lists  and  gives  a  set  of  lists  back 


sofirstlst[l^^,1^2'^bl'^b2^  > 

This  special  function  was  introduced  to  manage  the  operations 
where  a  set  of  first  lists  shall  be  retrieved: 


if  Itnat ( lenlst ( 1 ) , succnat ( succnat ( zeronat ( ) ) ) )  =  true ( ) 
then 

sofirstlst(l)  =  undef; 

else  if  eqnat  (lenlst  (1)  ,  siaccnat  (succnat  (zeronat  ()))  ) 

=  true ( ) 
then 

sof irstlst ( 1 )  =  firstlst(l); 

else  catlst(firstlst(l) ,sofirstlst(restlst(restlst(l) ) )  ) 
endi f ; 

where  the  criterion  for  the  operation  to  be  defined  is,  that 
the  list  must  have  at  least  two  elements  that  themselves  are 
lists  or  lists  of  lists,  which  is  stated  in  the  'if-then'  part 
of  the  axiom.  This  is  so  because  it  would  not  make  sense  to 
apply  'sof irstlst'  to  anything  else  besides  a  list  cf  lists. 

The  termination  condition  will  he  reached  when  the  list  has 
been  reduced  to  just  two  sublists  ('else-if  part).  In  all 
the  other  cases  the  first  element  of  the  first  list  ('firstlst 
( f i rst 1st ( 1 ) ) ')  will  be  concatenated  to  the  iterated  operation 
' sof irstlst ,'  now  applied  to  the  remaining  portion  containing 
all  other  lists  except  the  first  one.  Thus,  finally,  this 
operator  returns  every  first  list  from  the  sublists  of  list  1. 

Example ; 

if  I  lenlst(l^j^,1^2'^bl'^b2^  <  2]  =  trueO 
then 

sof irstlst [ 1^^ , 1^2 ' ^51 ' ^52 ^  ~  undef; 


since  the  length  of  list  1=4,  this  condition  does  not  hold 

and  the  'else-if'  part  is  tested 

else  if  1^2  '  ^bl' =  2]  =  true  ( ) 

which  is  not  true  either,  so  the  'else'  part  is  applied: 

else  catlst[l  ,  ,  sof irstlst  ( 1.  ,  1,  ^  )  ]  ; 

al  bl  b2 

thereby  initializing  the  repeated  application  of  the  operation. 
In  the  second  run,  the  'else  if*  condition  becomes  true, 
since  (lbl'^b2^  length  =  2 ,  so  the  'then'  statement 

is  applied: 

sof  irstlst  ( Ij^^  ,  lj^2  )  ~  ^bl' 

which  leads  to 

thereby  returning  the  set  of  first  lists  from  the  given 
list  1 . 


-•  .  .■  * 

.  .  • .  ■  I 
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The  last  operator  to  be  discussed  is  called  'retobjlst';  it 
takes  two  lists  as  an  input  and  returns  a  list.  It  was  intro¬ 
duced  with  the  intention  to  retrieve  all  the  lists  which  meet 
a  particular  condition 

retobjlst  [  (  /  ^32  '  ^a3^  '  ^  •^bl'^b2^  '  ■  ^cl '  ^c2  '  ^c3 '  ^  '  ^^b2^  ^ 

—  >  (lbi'^b2’  ' 

So  in  some  sense,  this  is  the  most  useful  operation  because  it 
allows  us  to  search  a  big  list  for  certain  sublists  without 
having  to  remember  all  the  details  about  the  sublists.  The 
axiom  is  short: 

if  eqlst  ( f  irstlst  ( 1  ,  nullst  ( )  )  =  true  ( ) 
then 

retob  j  1st  ( 1^ ,  I2 )  =  nullstO; 
else  if  irtlst  (I2 f f irstlst (1^) )  =  I2 


then 


'  ^  V  V 
V  V, 

V>>i 


cat 1st (firstlst (1^) , retob j lst(restlst(l^) ,12)) ; 


else  retobjlst  (restlst  (Ij^)  ,  I2)  ; 
endif ; 

and  states  that,  if  the  overall  list  to  be  searched  ( 1  )  ^or  a 
sublist  is  empty, this  list  can  not  be  contained  in  it.  Thus, 
the  result  is  the  empty  list  itself  ('if-then'  part),  which 
also  serves  as  the  termination  condition  for  the  recursion. 
Should  the  intersection  between  the  entered  list  I2  and  the 
first  list  of  1^  be  equivalent  to  I2/  the  entire  first  list  of 
1^  will  be  concatenated  to  the  repeated  operation  now  applied 
to  the  remaining  lists  of  1^  { ' else-if-then '  part).  This  en¬ 
sures  that  the  list  will  be  completely  scanned  since  more  than 
one  of  the  contained  sublists  could  meet  the  given  condition 
comprised  in  l2-  If  ^2  does  not  occur  in  the  particular  list 
being  searched  at  the  moment,  the  intersection  of  both  can  not 
be  equal  to  l2<  and  the  'else'  part  is  activated.  In  this 
case  the  operation  continues  without  saving  the  non-matching 
portion  of  1^^^.  When  finally  terminated,  a  concatenated  list 
is  available  that  comprises  every  single  list  of  1^  meeting  the 
predefined  requirement. 

Example : 

if  eqist  [  (1^^ , 1^2  '  ^ ^  ^  true() 

since  this  first  list  of  11  is  not  empty,  the  condition  doe 
not  hold  and  the  'eise-if  part  is  tested 

else  if  intlst[(l|^2^'^’al'^a2'^a3’^  =  ^b2 
does  not  hold  either,  so  the  'else'  part  is  applied; 

retobjlst[  (  ^  ^cl '  ^c2  '  ^c3  '  '  '  ^^b2'  ^ 

which  initializes  the  repeated  application  of  'retobjlst.' 
In  the  second  run,  the  'if'  condition  is  still  not  true,  so 


the  else-if  part  is  tested 


else  if  intlst[(lj^2>,(lj^^,lj^2^]  = 


since  the  condition  holds,  the  'then'  statement  is  executed 
then 


catlst  [  ,retobjlst  (  d^^,1^2'  ^c3'  '  '  ' 


which,  again,  initializes  'retobjlst.' 

In  the  third  run,  this  leads  to  the  application  of 
retobj  1st  [  ( )  ,  ( lj^2  ^  ^ 

but  now  the  'if  condition  is  true  and  the  entire  operation 


results  in  the  concatenation  of  [  ( 1,  ,  )  ,  ( 1,  -, )  ]  with  the 

bl  bz 


empty  list,  which  gives  us  final  result. 


As  discussed  earlier,  the  queue  mechanism  has  to  be  used  as 
an  intermediate  storage  process  to  ensure  that  none  of  the 
retrieved  lists  will  be  lost.  By  means  of  parameterization 
al 1  the  operators  described  in  the  mathematical  part  of  the 
specification  (spec  property_id  through  spec  database)  Cc.r  he 
appli.ed  using  the  adequate  list  operations.  This  is  achieved 
by  short  hybrid  specifications  (spec  pidlist  through  spec 
dblist)  which  combine  the  parameters  defined  in  'spec  list' 
with  the  corresponding  operators  of  the  original  specifications 
giving  access  to  all  the  operations  of  data  type  '1st.' 


D.  THE  LIST  STRUCTURE  APPLIED  TO  DATABASE  DESIGN 

In  this  section  we  describe  how  the  application  of  the  list 
theory  supports  the  fundamental  database  operations.  Since 
the  structure  of  the  abstract  database  can  be  compared  with  a 
large  list,  this  concept  will  be  discussed  in  more  detail. 
Starting  with  the  basic  elements  ' property_id '  and  'value,' 
each  of  the  related  data  types  may  be  considered  as  forming  a 


list  containing  just  the  single  element  •  pid>  or  <val'>,  whi.le 
their  sets  are  represented  by  lists  consisting  of  as  many  snb- 
lists  as  required,  for  example. 


< pidl  >  ,  <pid2  >  >  or  <  <  vall>  ,  <val2  >  ,  <val  3  >  >  . 

Consequently,  a  'property*'  which  is  defined  by  a  'pid'  and  a 
'valset'  can  be  expressed  by  means  of  a  list  containing  these 
two  major  sublists  as  elements,  where  the  second  list  is  itself 
composed  of  a  number  of  single  lists: 

•pid>,"'  <vall  ,' val2 '■vain  ■’  > 

Adding  another  ' < '  at  the  beginning  and  one  ' ^ '  at  the  end 
combines  several  properties  into  a  ' propertyset . '  Applying 
this  technique  to  ' propertyva lue '  which  represents  an  instance 
of  a  property,  the  resultant  looks  like  the  follov;ing: 

■  pid_> ,  <val ''  > 

and  the  corresponding  set  can  be  created  by  combining  the 
necessary  number  of  adequate  ordered  pairs 

'  pi  dl <  val  1  >  >  ,  ■;  •'-.pid2  >  ,  <- val2  >  pidi  ' ,  ■  val  i 

To  construct  an  'object'  is  nov;  straightforward  since  the  ob¬ 
ject  is  nothing  more  than  a  particular  ' propertyvalueset '  it¬ 
self.  The  '  ob  jectclass '  then  can  be  considered  as  a  num.ber  of 
different  objects  put  into  the  same  list.  But  caution  has  to 
be  taken  that  we  do  not  violate  our  definition  of  a  class. 

Since  objects  can  only  be  grouped  together  if  they  are  struc¬ 
tured  in  a  similar  way,  it  is  mandatory  that  they  contain  exactly 
the  same  number  of  corresponding  'pids.' 


A  'class'  can  be  expressed  by  a  list  of  the  form: 

<  <  <  ;pidl > , <valll>  <pidi > , <valil >  >  ■, 

■  ^  < pidl > , < vall2 >  <pidi> , <vali2 >  >  ■, 

•  •  •  «  •  •  • 

•  »  •  ■  •  •  • 

<  <pidl> ,  <vall  j  >  <pidi> ,  <vali  j  >  >  >; 

where  the  kind  and  number  of  'pids'  is  the  only  criterion  for 
associating  a  given  object  to  a  certain  class,  while  any  'value 
necessary  for  describing  an  object  can  legally  be  attached  to 
a  'pid'  as  long  as  it  is  defined  in  the  appropriate  domain. 

Finally,  the  database  can  be  treated  like  a  big  list  con¬ 
taining  several  lists  of  the  class  type  just  described,  where 
the  same  criteria  must  be  met  on  a  higher  level.  To  see  how 
an  operation  on  this  list  structure  works,  let's  consider  the 
disjoint  operator  for  'pidsets': 

intpidset  (pidsetl ,  pidset2)  — >  pidset.l; 
where,  for  example, 

pidsetl  =  ■ pidl> , ' pi d2 >  ' ; 

pid set 2  =  ■ pidl  ' ,  ; pi d3 >  >. 

In’-oking  the  parameterized  spec  pidsetlist  gives  us  access  to 
both  spec  ] ist  and  spec  property_idset .  'Intpidset'  is  then 
replaced  by  'intlst'  which  by  substitution  leads  to  the 
operat ion 

intlst('  ‘pidl-,  pid2''  ■,>  <pidl>,<pid3>  >). 


Since  operator  'intlst'  is  handled  by  the  recursive  axiom 


(eqlst ( 11 , nullst ( ) )  =  true ( ) ) , 

(eqlst  ( 12  ,  nullst  ( )  )  =  trueO) 

)  =  trueO 
then 

intlstif irstlst (11) , 12)  =  nullstC); 
else  if  memblst  (f  irstlst  (11)  ,  12)  =  trueO 
then 

cat 1st (firstlstCll) ,intlst{restlst(ll)  ,12)  )  ; 
endif ; 

first  the  termination  condition  is  checked,  which  means,  if 
either  of  the  two  lists  is  empty  then  the  intersection  must 
be  equal  to  the  null-list  ('if-then'  part).  In  our  particular 
case  they  are  not  empty,  so  the  'else-if'  part  will  be  tested. 
Since  the  first  list  ('<pidl>')  of  11  ( ' < <pidl > , <pid2 > > ' )  is 
contained  in  12  ( ' < <pidl > , <pid3>> ' ) ,  this  condition  holds  and 
the  concatenated  list  (  '  catlst  [  <pidl  > ,  intlst  (  (  <pid2  > )  ,  ( ■^pidl  >  , 
'-pid3>))]')  is  created  where  'intlst'  invokes  a  recursive  opera 
tion  on  the  rest  of  11  ('<pid2>')  and  12  ( ' <pidl > , <pid3 > ' ) . 

This  time,  since  neither  the  'if  nor  the  'else-if'  part  is 
true,  the  'else'  condition  is  applied  which  leads  to  a  repeated 
operation  on  the  rest  of  11  and  on  12: 

intlst[<>, (<pidl>,<pid3>) ] . 

Now  the  'if  part  of  the  axiom  becomes  true  which  returns  the 
empty  list.  This  results  in  the  concatenation 

catlst(<pidl>,^>) 

and  gives  '<pidl>'  as  the  intersection  of  11  with  12. 


E. 


LIST  RETRIEVAL 


In  the  previous  sections  we  developed  the  abstractions  of 

the  database  resource  and  discussed  the  set  of  operators  that 

apply  to  database  progranming.  In  AM  (version  2.0)  the  'state' 

of  the  machine  consists  of  the  aggregation  of  the  memory, 

register,  stack  cell  contents,  display  register  and  monitor. 

We  will  now  extend  the  'state'  to  include  the  new  entity  'queue 

1 .  Background  on  the  Processor  Resource 

For  a  better  understanding  of  the  applied  extension, 

in  the  following  paragraph  a  brief  description  of  AM,  taken 

from  Hunter  [Ref.  3],  will  be  presented. 

In  AM  (version  1.0)  the  five  primitive  data  types, 

boolean,  natural,  integer,  character,  and  string,  form  the 

atomic  data  types  and  are  referred  to  as  'atoms.'  Yurchak 

[Ref.  2]  as  the  implementor  of  AM.  discussed  the  impact  of  the 

relationship  between  the  data  and  a  conventional  machine  on 

portability  issues  in  detail,  and  identified  the  following 

properties  of  AM  which  were  used  to  reduce  the  "semantic  gap" 

and  give  AM  .its  uniqueness: 

in  the  organization  of  primary  storage,  the  next 
logical  data  item  is  in  the  next  logical  address; 

except  as  formally  specified,  no  data  type  may  be 
accessed  in  any  way,  as  another  data  type; 

given  any  arbitrary  logical  address,  the  value  stored 
there  and  its  type  can  always  be  determined. 

The  processor  portion  of  AM  is  an  abstraction  of  a  conventional 

"Von  Neumann"  machine  with  some  unconventional  properties. 

The  only  machine  element  is  called  a  'value.'  All  data 


primitives  (atoms)  map  into  values.  Spec  typing,  as  introduced 
by  Hunter,  describes  the  relationship  of  'values'  and  'atoms.' 
As  an  illustration  of  this  relationship  consider  the  inter¬ 
sect  operation  on  two  'pidsets.'  VJe  fetch  the  value  represen¬ 
tation  of  the  first  'pid'  of  each  set  from  two  registers,  and 
convert  each  value  to  its  'pidset'  atom  with  the  ' atomof pidset ' 
operator.  The  'pids'  are  intersected  in  accordance  with  the 
'pidset'  data  type,  and  the  resulting  'pid'  is  converted  back 
into  a  value  with  ' valof pidset '  for  storage  into  a  register. 

The  operation  will  be  continued  recursively  until  both  'pidsets 
are  completely  intersected. 

Primary  storage  is  an  array  of  one  or  more  memory  seg¬ 
ments,  each  of  which  may  contain  an  arbitrary  number  of  cells. 
Each  cell  is  capable  of  "containing"  any  legal  data  value. 

Both  programs  and  data  may  reside  together  in  a  single  segment. 
For  high  speed  storage,  there  are  one  or  more  register  seg¬ 
ments,  each  of  which  contains  an  arbitrary  number  of  registers. 
AM  also  has  one  or  more  stacks,  a  heap,  a  crude  file  system, 
and  now  a  queue.  Again,  every  register,  stack  and  queue  cell 
is  capable  of  containing  any  type  of  data. 

The  basic  atomic  data  types  are  augmented  by  several 
others  needed  for  the  execution  of  programs.  These  are  in¬ 
structions  and  memory,  register,  stack,  file  addresses,  and 
the  queue. 

2 .  The  Queue 

The  value  representation  of  the  new  data  types  'pid,' 
'pidset,'  'val,'  'valset,'  'prop,'  'propset,'  'pval,'  'pvalset,' 


'obj,'  'class, 'and  'db,'  may  be  placed  in  any  memory,  register, 
or  stack  cells  with  one  exception:  whenever  a  set  of  'pids,' 
'vals,'  'pvals'  or  'objs'  will  be  retrieved,  they  can  not  be 
displayed  until  they  are  first  placed  in  the  queue.  The  con¬ 
cept  of  the  queue  is  similar  to  a  stack.  Since  we  do  not  v/ant 
the  programmer  to  have  access  to  the  "inside"  of  the  queue  nor 
want  to  provide  facilities  for  altering  the  queue  in  any  way, 
we  make  its  use  only  available  for  the  very  special  purpose 
of  acting  as  a  buffer  for  the  data  retrieved  from  the  database 
so  it  can  be  returned  to  the  programmer  when  a  search  is  com¬ 
plete.  The  reason  for  introducing  the  queue  is  that  the  order 
always  matters  in  a  database.  Thus,  a  stack  which  reverses  the 
sequence  between  inputs  and  outputs  would  not  work  for  this 
case.  The  queue  preserves  the  order  in  which  data  is  entered, 
and  although  queue  operations  are  more  difficult  to  specify 
than  the  stack  operations,  it  finally  was  adopted. 

To  make  the  queue  mechanism  operational  in  a  similar 
way  as  the  stack,  instructions  were  installed  for  opening/ 
closing  and  reading/writing  ('spec  instructions'),  while  the 
operations  for  defining  the  state  of  the  queue  and  their  meaning 
were  added  to  'spec  amstate.'  The  program  portion  is  described 
in  'spec  am'  which  makes  the  queue  an  integrated  part  of  AM. 

The  database  resource  can  be  invoked  by  the  operator 
' opendb '  which  requires  a  characterstring  as  identifier,  a 
database,  a  state,  and  returns  a  state.  Provision  for  closing 


the  database  is  made  by  the  operator  'closedb'  which  require 
a  database  and  a  state  as  input  and  returns  a  state,  thereby 
terminating  the  access. 
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VI.  IMPLEMENTATION 


At  present,  only  the  original  AM,  version  1.0,  is  imple¬ 
mented  and  operates  as  a  finite  state  machine  interpreter.  It 
comprises  approximately  12,000  lines  of  C  code,  including  the 
assembler.  De-'^eloped  by  Yurchak,  the  overall  concept  for  the 
assembler  is  as  simple  as  it  is  effective.  A  text  file  repre¬ 
senting  an  assembly  language  program  is  translated  by  the 
assembler  into  a  relocatable  object  module.  A  loader,  part  of 
the  AM  interpreter,  then  loads  this  object  module  into  the 
appropriate  cells,  and  AM  executes  it.  The  reader  is  referred 
to  Appendix  C  for  more  details  about  the  assembler. 

Since  Yurchak  [Ref.  2]  as  the  originator  provides  a  complete 
description  of  the  AM  implementation,'  we  will  repeat  major 
portions  of  his  work  but  also  consider  points  of  interest  found 
in  Hunter's  [Ref. 3]  description  of  the  version  2.0  extension 
while  finally  adding  s  me  examples  and  discussion  of  our  latest 
modification  towards  AM,  version  3.0. 

For  time  reasons,  neither  the  bit-mapped  display  nor  the 
database  resource  have  actually  been  implemented.  Rehosting  the 
original  AM,  version  1.0-Unix  from  a  VAX  780  to  a  Zenith  ZlOO 
microcomputer  by  Hunter  manifested  once  again  all  the  typical 
difficulties  known  as  "the  portability  problem."  This  rehost¬ 
ing  required  approximately  350  functions  to  be  renamed 
throughout  the  12,000  lines  of  code,  since  the  compiler  and 


linker  now  used  operate  on  shorter  character  names  only. 

Another  problem  Hunter  faced  during  the  re- implementation  of 
version  1.0  was  that,  although  the  Unix  C  compiler  allowed 
passing  of  structures  by  value,  the  Lattice  C  compiler  for  the 
Zenith  version  does  not,  so  the  entire  program  had  to  be 
converted  to  passing  structures  by  pointer.  Thus  major  parts 
of  the  initial  AM  had  to  be  modified  or  rewritten  by  Hunter. 

But  despite  these  problems  usually  encountered  when  porting 
software,  the  number  of  test  programs  developed  for  the  Unix 
version  run  on  the  Zenith  ZlOO  with  the  same  results.  So  far 
the  assembler  has  been  revised  to  handle  the  full  extension 
for  both  versions  2.0  and  3.0,  including  all  new  data  types, 
the  resource  extensions,  plus  some  additional  operators  for  the 
original  data  types,  as  mentioned  before.  The  machine  itself 
however,  has  not  yet  been  extended  to  handle  the  new  data  types 
introduced  by  the  gradual  modification.  This  remains  for 
some  future  work. 

After  this  description  of  the  present  state  of  the  AM 
development,  we  will  now  continue  with  the  overview  of  the 
implementation.  There  are  four  main  areas:  the  representation 
of  data  types,  the  mapping  of  operators  in  the  specification  to 
functions  in  the  interpreter,  the  handling  of  errors,  and 
the  execution  of  a  program. 

A.  implementing  data  types 

Since  it  provided  an  easy  translation  from  the  specifica¬ 
tion,  C  was  adopted  by  Yurchak  as  the  corresponding  programming 


language  for  AM.  But  as  he  states  in  his  work,  another 
language,  like  LISP  might  have  done  the  job  as  well. 

AM  is  a  tagged  architecture.  Each  data  element  or  value 
must  be  self-descriptive.  As  Hunter  points  out,  it  is  impor¬ 
tant  to  realize  the  distinction  between  an  atom  which  corres¬ 
ponds  with  a  data  type,  and  a  value.  In  contrast  to  an  atom 
that  is  referred  to  as  sort  in  our  specifications  and  repre¬ 
sents  a  problem  solving  abstraction  like  'pid'  or  'obj'  for 
the  database,  a  value  embodies  a  machine  element.  Furthermore 
an  atom  is  representation  independent  and  keeps  its  level  of 
abstraction,  while  a  value  is  the  specific  representation  of 
such  an  atom.  Representation  independence  is  achieved  by  cer¬ 
tain  conversion  functions  (Appendix  B)  that  map  all  atoms  into 
appropriate  values  and  vice  versa.  This  translati.on  technique 
enables  us  to  determine  the  type  of  a  value  solely  from  the 
value  itself,  which  is  one  of  the  distinct  properties  of  AM 
and  gives  the  machine  its  tagged  architecture,  introduced  to 
ease  the  "portability  problem."  The  most  likely  construct  to 
pro'/ide  this  feature  is  a  structure  (record). 

Each  atom  is  represented  in  C-language  as  a  structure  con¬ 
sisting  of  a  16-bit  tag  field,  and  a  value  field.  The  size  of 
the  valuer  field  varies  with  the  type.  Fach  sort  in  the  speci¬ 
fication,  as  the  equivalent  to  an  atom,  is  assigned  a  16-bit 
code.  Whenever  an  atom  is  created,  or  copied,  it  is  tagged 
with  the  appropriate  code.  Figure  VI . 1  lists  some  fragments 
from  the  header  files  used  by  our  interpreter  and  represents 


the  'natural'  data  type  which  has  a  simple  value  field. 

Hunter  [Ref.  3]  compressed  the  initial  term  'NAT_TYPE'  to  the 
handier  'T_NAT'  for  the  reasons  given  above. 


/*natural  type  tag*/ 


#define  T_NAT  0x0002 

typedef  unsigned  intnat; 

typedef  struct  { 
short  type; 
nat  val; 

}  NAT; 


Figure  VI . 1 .  Type  Definitions  for  Natural 


By  using  a  fixed  size  tag  field  as  the  first  field  in  each 
record,  we  build  in  some  additional  robustness  since,  even 
in  the  event  of  a  mistyped  structure  being  copied  into  the 
formal  parameter  of  a  function,  we  can  rely  upon  the  first 
word  to  be  a  valid  code  (the  type) . 

The  next  step  is  to  describe  the  structure  for  machine 
values  that  must  be  capable  of  containing  any  atom.  To  manage 
this  problem,  Yurchak  introduced  the  union  operation  which 
involves  every  single  sort  defined  in  the  specifications  so 
that  any  atom  can  be  represented  by  the  value  structure.  Due 
to  the  "ZlOO"  characteristics,  the  value  structure  is  divided 
into  portions  of  two  bytes  for  the  tag  field  and  four  bytes 
for  a  pointer;  the  data  type's  value  will  be  represented 
either  directly  in  such  a  value  field  or,  if  it  can  not  be 
expressed  within  the  space  of  the  four  bytes  available. 
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a  pointer  to  its  real  location  is  used.  String  and  list  struc¬ 
tures  are  examples  that  use  pointers  since  their  size  is  varia¬ 
ble  and  usually  large. 

Figure  VI . 2  shows  the  concept  of  the  union  structure  for 
machine  values  VAL.  Because  the  number  of  data  types  increased 
very  much  in  the  latest  modification  of  AM,  only  a  sample  of 
the  values  actually  present  is  given.  Hunter  [Ref.  3]  also 
notices  that  INSTR  itself  represents  a  VAL  pointing  to  another 
VAL  which  contains  the  instruction's  opcode.  By  this  tech¬ 
nique  it  becomes  possible  to  fetch  and  store  instructions, 
thereby  allowing  us  to  put  a  program  into  memory  and  to  execute 
i  t . 

The  primary  physical  resources  are  also  defined  as  struc¬ 
tures.  A  sam’-  le  of  these  resources  is  presented  in  Figure  VT ,  3 
Registers,  display  registers,  memory  and  stacks  are  represented 
as  arrays  of  arrays  of  pointers  to  values.  The  reader  should 
note  that  a  simple  change  to  the  constants  in  the  header  files 
can  completely  alter  the  configuration  of  the  machine.  We 
can  specify  an  arbitrary  number  of  arbitrary  long  memory, 
register  and  display  register  segments,  as  well  as  different 
sizes  for  an  arbitrary  number  of  stacks  and  the  queue.  Data¬ 
base  and  file  are  represented  as  an  array  of  structures,  with 
the  files  containing  an  input/output  buffer  in  addition  to  the 
status  information  contained  in  both.  The  number  of  separate 
databases  or  the  number  and  type  of  files  can  be  changed  by 
recompiling  the  corresponding  module  of  the  interpreter. 


typedef  short  opcode; 

typedef  struct  { 
short  type; 
union  value  *val; 

}  INSTR 

typedef  union  value  { 
short  type; 

opcode  opcdval;  /*this  is  the  compressed  version 

of  the  initially  used  term 
' opcodeval ' */ 

BOOL  boolval;  /*starting  here  the  data  types 

INT  intval;  are  listed*/ 


FONT  fontval ; 
LIST  listval; 


MAD  madval;  /*memory  address*/ 

QADDR  qaddrval;  /*queue  address*/ 


INSTR  instrval; 

MOP  monval;  /*monadic  operator*/ 

DOP  dopval ;  /*dyadic  operator*/ 

;  VAL  ; 


Figure  VI . 2 . 


Machine  Values 


typedef  struct  ( 
int  size; 
VAL  **val; 

}  memseg; 

typedef  struct  ( 
int  size; 
int  sp; 

VAL  **val; 

}  stkseg; 

typedef  struct  { 
int  size; 
VAL  **val; 

}  qseg; 

typedef  struct  ■' 
int  stat; 
int  mode; 
int  type; 
int  ^^al; 

;  fileseg; 

typedef  struct  { 
int  stat; 
int  val; 

}  dbseg; 

(fdefine_NUMMEMSEG 
#define_NUMSTKSEG 
#define__NUMQSEG 
#def ine_NUMFILES 
# define  NUMDB 


1024 

1 

1 

16 

1 


/*memory  segment*/ 


/*stack  segment*/ 


'*queue  segment*/ 


/*file  segment*/ 


/*database  segment*/ 


/*defined  for  1  database*/ 


memseg_mem [_NUMMEMSEG] 
1024,0 
1024,0  }  ; 

stkseg_stk [_NUMSTKSEG] 
512,512,0  }  ; 
qseg_q  [_NIIMQSEG]  =  ' 
512,512,0  }  ; 


Figure  VI. 3.  The  Physical  Resource 
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With  respect  to  the  characteristic  requirements  for  re¬ 
trieving  selected  contents  from  the  database,  the  queue  was 
provided  to  act  as  a  buffer.  Since  this  is  the  primary  reason 
for  the  queue,  its  accessibility  has  been  limited  to  serve  just 
this  purpose.  There  are  in  fact  only  three  ways  of  accessing 
the  queue,  either  directly  or  via  main  memory  and  register 
operations  that  directly  lead  to  the  physical  address  of  the 
data.  The  database  must  be  opened  similar  to  a  file  in  order 
to  perform  the  desired  operations,  and  must  be  closed  again 
when  the  operations  are  terminated. 

B.  MAPPING  OPERATORS  TO  FUNCTIONS 

It  seems  natural,  although  incorrect,  to  look  at  the 
operators  in  a  spec  as  functions.  However,  in  the  implementa¬ 
tion,  this  makes  perfect  sense.  Figure  VT . 4  lists  the  code 
for  the  AM  module  which  implements  the  boolean  type.  The 
header  files  which  provide  the  constant  definitions  are  omitted 
here.  Notice  that,  where  possible,  we  rely  upon  the  operations 
provided  by  the  C  language,  rather  than  slow  down  an  already 
slow  interpreter  with  axiomatic  implementations  of  the 
operators . 

As  the  implemenrati on  proceeds  to  more  complex  specifica¬ 
tions,  the  program  relies  less  upon  C  and  more  upon  the  opera¬ 
tors  which  we  have  defined.  In  fact,  the  more  complex  operators 
are  implemented  as  calls  to  pr' -viously  defined  functions  which 
almost  directly  mimic  the  axioms  from  which  they  are  derived. 


BOOLtrue  =  ''  T_BOOL,L  ;;  /*the  initially  used  BOOL_ 

TYPE  was  replaced  by  the 
more  complex  term  T_BOOL*/ 

BOOLfalse  T_BOOL,0  }  ; 

BOOL  *not(a) 

BOOL  a ; 

BOOL  *tmp;  /*'tmp'  was  installed  by 

Hunter*/ 

tmp  =  (BOOL* ) tmalloc (sizeof (BOOL) ) ; 
tmp->type  =  T_BOOL; 
tmp->val!=  a->val; 
return ( tmp) ; 

BOOL  *and (a , b) 

BOOL  *a,*b,: 

BOOL  *tmp; 

tmp  =  (BOOL* ) tmalloc (sizeof (BOOL) ) ; 
tmp- > type  =  T_BOOL; 
tmp->val  =  (a->val&&b->val) ; 
return ( tmp) ; 

BOOL  *eqbool(a,b) 

BOOL  *a,*b; 

BOOL  *tmp; 

tmp  =  ( BOOL* ) tmal loc (s i zeof ( BOOL) ) ; 
tmp- 'type  =  T_B00L; 
tmp-  'val  =  (a-  ’val  ==  b-'’val)  ; 
return ( tmp) ; 

BOOL  *nebool(a,b) 

BOOL  *a,*b; 

BOOL  *tmp; 

tmp  =  ( BOOL* ) tma 1 loc ( s izeof ( BOOL) ) ; 

tmp-  'type  =  T_BOOL; 
tmp->val  =  (a-  val  !=  b- -val) ; 
return ( tmp) ; 

BOOL  *or(a,b) 

BOOL  *a,*b; 

BOOL  *tmp; 


Figure  VI . 4  Operator  to  Function  Mapping  for  Type  BOOL 
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tmp  =  (BOOL*) tmalloc {sizeof (BOOL)  )  ; 
tmp->type  =  T_BOOL; 
tmp->val  =  (a->val  ;  b->val) ; 
return (tmp) ; 


Figure  VI . 4  (CONTINUED) 


C.  ERROR  HANDLING 

The  method  of  treating  errors  was  entirely  revised  by 
Hunter.  All  errors  in  the  specifications  are  now  described  with 
the  'undef'  operator.  By  definition,  that  maJces  all  errors 
fatal,  but  they  need  not  be.  Those  errors  which  are  not,  must 
then  be  defined  explicitly  in  the  specification.  As  remarlced 
earlier,  a  more  detailed  treatment  of  errors  would  be  an  area 
for  further  study. 

AM  flags  most  errors  in  the  operators  which  perform  data 
conversions.  This  is  a  natural  place  for  this  to  occur,  since 
It  is  difficult  to  see  how  the  type  of  a  data  element  may  be 
changed  at  any  other  time.  Figure  VI . 5  shows  a  fragment  which 
implements  the  ' property_id '  conversion  routines.  The  routine 
'error'  does  not  return,  but  terminates  execution  after  writing 
the  error  message  to  'stderr.'  Notice  that,  even  if  a  much 
larger  structure  was  passed  to  'atomofpid'  or  'valofpid,'  the 
error  would  be  detected  and  handled  gracefully. 

This  type  of  error  checJ^ing  is  also  performed  in  the  func¬ 
tions  which  implement  data  operations. 


136 


/*short  form  for  atomofpid*/ 


PID  *atpid(v) 

VAL  *v; 

■f 

PID  *b; 

if(v->type  !=  V_PID)  /*reduced  term  for  PID_VAL*/ 

errorC'value  not  of  type  PID  -%x",  v->type)  ; 
b  =  (PID*) tmalloc (sizeof (PID) ) ; 

b->type  =  T_PID;  /*reduced  term  for  PID_TYPE*/ 

b->val  =  v->pidval . val ; 
return (b) ; 

} 

VAL  *vlpid(b)  /*short  form  for  valofpid*/ 

PID  *b; 

{ 

VAL  *v; 

if (b->type  !=  T_PID) 

errorC'atom  not  of  type  PID  -%x"  ,  b->type)  ; 

V  =  (VAL*) tmalloc (sizeof (VAL) ) ; 

V- >pidval . type  =  V_PID; 
v->pidval . val  =  b->val; 
return ( v) ; 


Figure  VI . 5 .  Error  Handling  Routine  for  Property_id  Type 


D.  EXECUTION 

The  final  point  of  interest  involves  actually  executing  a 
program.  The  method  is  also  illustrative  of  the  way  in  which 
the  program  mimics  the  axioms  of  the  specification.  Here, 
too,  we  resort  to  subterfuge  to  implement  in  a  finite  way  a 
specification  which  could  require  the  expenditure  of  an  infinite 
resource  (an  implied  stack  in  this  case) .  The  problem  is  the 
corecursive  relationship  between  the  functions  'xeq'  and 
'prog.'  We  eliminate  this  problem  by  never  actually  returning 
from  'xeq.'  We  rely  on  a  dangerous  but  effective  C  idiom, 
'setjmp'  and  'longjmp,'  Figure  VI . 6  illustrates  this. 


main (argc , argv) 
char  *argv[]; 

{ 

int  ap; 

for  (ap=l;ap<argc;ap++)  { 

if  (*argv[ap]  ==  '-')i 
if  ( *  (argv [ap] +1)  = 
traceflag  =  1; 
xtraceflag  =  1; 

} 

if  ( * (argv [ap] +1)  = 
traceflag  =  1; 

} 

initiam( ) ; 

araload ( ) ; 

set jmp (_context)  ; 

Q  =  prog (&_pc,Q) ; 
exit ( 0 ) ; 


STATE  prog(m,q)  /*program  for  prog*/ 

MAD  *ni; 

STATE  q; 

q  =  xeq (atinstr (fetchm(m,q) ) ,m,q) ; 

/*short  term  for  atomof instr*/ 


STATE  xeq(i,m,q)  /*program  for  xeq*/ 

INSTR  *i; 

MAD  *m; 

STATE  q ; 

{ 

opnd  *p; 

if  (i->type!=T_INSTR)  /*short  term  for  INSTR_TYPE*/ 

error ( "attempt  to  execute  non-instruction  -%x" ,  i->type) 
p  =  i->val; 

switch (getopcode (p [0] .opcodeval) ) { 

/*a  case  and  semantics  for  each  valid  opcode  goes 
here*/ 
default ; 

error ( "attempt  to  execute  an  illegal  instruction  -%x" , 
p[0] .opcodeval) ; 

} 

longjmp(  context,!); 


/*check  for  toggles*/ 
:=  '  X  '  )  { 

/*added  by  Hunter*/ 

=  -f) 

/*main  body*/ 


Figure  VI . 6 .  Program  Execution 
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In  'main,'  'initam'  configures  AM  and  invokes  all  of  the 
initialization  operators.  'Amload'  loads  a  program  from  secon¬ 
dary  storage  into  the  appropriate  cells  as  directed  by  the 
linker  directives  in  the  object  module.  'Setjmp'  then  saves 
the  state  of  the  "real"  machine.  The  variable  '_pc'  is  the 
program  counter  v/hich  is  set  inside  'amload.'  Now  everything 
is  set.  The  program  is  loaded  and  ready  to  run. 

'Prog'  is  now  called.  Notice  that  'prog'  simply  invokes 
'xeq.'  Recall  now  the  axiom  which  defines  the  semantics  of 
execution : 

prog(m,q)  =  xeq (atomof instr ( f etchm (m, q) ) , m , q) ; 

The  value  of  a  language  which  permits  usefully  long  names  is 
obvious  in  this  case.  Within  'xeq'  a  large  case  statement 
decodes  the  instruction  and  executes  it  according  to  the 
semantics  provided  for  that  case.  This  semantics  is  very  closely 
modeled  on  the  axioms  in  the  specification.  Figure  VI . 7  shows 
one  such  case  and  its  accompnaying  semantic  action. 

case  IM_M_M; 
q  =  storem( 

f etchm ( 

&p  LI] .madval, 

q 

)  , 

&p [2 ] . madval , 

q 

)  ; 

_pc.val  =  nxtmad (m) ->val ; 
break 

Figure  VI. 7.  The  Semantics  for  'mov  m  m' 


/*val  of  memaddr  pointed  to 
by  p[l]*/ 

/*q : state*/ 


Now  compare  Figure  VI . 7  to  the  axiom  for  mov_m_m. 

xeq (mov_m_m (ml ,m2 ) ,m, q)  = 
prog  ( 

nxtmad (m) , 
storem ( 

f etchm (ml ,q) , 
m2 , 

q 

) 

)  ; 

The  similarities  are  not  accidental.  This  should  make  the 
point  that  it  is  beneficial  for  the  implementation  language 
to  permit  such  a  close  modeling  of  the  specification.  Obvious] 
this  made  the  implementation  easier  to  write,  debug  and 
understand . 

E.  DATABASE  IMPLEMENTATION  ISSUES 

Similar  to  a  file  system,  the  database  consists  of  two 
major  parts:  the  information  contained  in  it  and  the  program 
that  allows  the  user  to  manipulate  this  implementation.  Once 
implemented,  both  program  and  content  of  the  databases  are 
rather  fixed,  although  the  information  part  can  gradually  be 
changed  by  iterated  application  of  the  appropriate  commands. 
Thus  in  general  the  user  is  limited  to  retrieving  or  modifying 
the  stored  information,  but  this  is  the  main  purpose  of  a  data¬ 
base.  Should  a  conceptual  change  of  the  contents  become  neces- 
sary  after  a  while,  it  is  more  convenient  to  revise  the  kind 
and  arrangement  of  the  data,  and  let  the  entire  database  then 
be  re- implemented  by  an  application  programmer. 


Theoretically,  there  exist  no  boundaries  for  the  size  of 
our  abstract  database,  which  means  objects  can  be  defined  by 
any  number  of  propertyvalues ,  and  classes  may  contain  any 
number  of  objects.  But  in  reality  we  cannot  ignore  the  capa¬ 
bility  of  the  available  physical  resources.  Since  databases 
tend  to  increase  rapidly,  the  capacity  of  the  attached  storage 
device  will  set  the  natural  limit. 

Practically  speaking,  a  user  would  need  a  DDL  tool  to 
effectively  create  a  database,  just  as  a  compiler  would  be 
needed  to  effectively  write  programs  for  AM.  The  purpose  of 
this  thesis  however,  is  to  give  a  precise  specification  of  the 
low  level  resources  needed  for  a  database. 

The  particular  commands  accessible  by  the  user  will  be 
fully  integrated  into  the  AM  instruction  set.  They  mainly 
consist  of  the  operations  described  in  spec  objectclass  and 
spec  database  and  are  considered  sufficient  to  perform  all  the 
necessary  data  manipulations.  The  operators  provided  permit 
the  insertion  and  deletion  of  an  object  into/from  a  given  class 
the  update  of  an  object  by  modification  of  its  contents,  and 
the  selection  of  one  or  more  objects  in  accordance  with  a 
predefined  condition.  As  soon  as  the  database  part  of  AM  is 
invoked  (instruction  'opendb')  the.se  commands  can  be  applied 
to  the  contents  representing  this  database  after  they  are 
brought  into  main  memory  first.  For  any  change,  data  are 
fetched  from  their  memory  location,  loaded  into  a  register, 
and  stored  back  when  the  operation  is  completed.  After 


termination  of  the  desired  activities  the  database  must  be 
closed  (instruction  'closedb')  and  the  data  will  be  transferred 
back  to  secondary  storage.  This  procedure  ensures  that  the 
data  residing  in  secondary  storage  at  the  end  of  the  operation 
always  represent  the  actual  state  of  the  database.  A  presorting 
of  data  outside  main  memory  is  not  feasible,  since  we  do  not 
presume  the  existence  of  an  additional  processor  which  is  usually 
known  as  back-end  computer. 

To  select  an  object  on  the  basis  of  a  certain  entity  by 
which  it  is  defined,  called  ' propertyvalue '  ( ' pv ' )  in  our 

terminology,  the  characterizing  'pv'  will  be  loaded  into  a 
register  as  a  comparand.  Identified  by  the  corresponding 
' property_id '  of  this  'pv,'  the  class  possibly  containing  the 
required  object  is  then  localized  and  the  entire  'pv'  set  of 
its  first  object  will  be  loaded  into  a  separate  set  of  registers. 
If  a  match  occurs  between  the  comparand  and  the  register  con¬ 
taining  the  adequate  'pv'  of  the  object,  the  total  'pv'  set  is 
copied  into  the  queue  and  the  next  object  will  be  loaded.  If 
no  match  takes  place  the  procedure  will  be  continued  without 
storing  the  object  in  the  queue.  VJhen  the  entire  class  has 
been  searched,  the  'select'  operation  terminates  and  the  resul¬ 
tant  object (s)  can  be  read  from  the  queue.  The  state  of  the 
database  will  not  be  changed  by  this  operation  since  only  a 
partial  copy  is  taken.  But  it  can  not  be  excluded  that  none  of 
the  objects  would  meet  the  criterion  searched  for.  In  this 
case  no  copy  will  reside  in  the  queue  and  the  returned  'pv' 
set  is  empty. 


In  contrast  to  the  'select'  operation,  which  can  be  con¬ 
sidered  as  a  read  function,  insertion,  deletion,  and  modifi¬ 
cation  actually  do  change  the  given  state  of  the  database,  so 
these  operations  are  a  little  more  complicated.  Inserting 
a  new  object  requires,  besides  the  'pv'  set  that  defines  it, 
the  class  to  which  it  is  inserted.  This  technique  ensures  that 
no  object  accidentally  will  be  inserted  which  is  not  attached 
to  a  certain  class.  Without  this  restriction,  the  structure 
of  the  database  could  be  changed  in  an  unacceptable  way.  When 
the  class  has  been  identified  by  comparison  of  the  correspond¬ 
ing  ' property_ids '  the  new  object  will  be  added  at  the  end  of 
that  class.  An  error  handling  routine  is  invoked  should  the 
required  class  not  exist. 

At  this  point  the  question  must  be  answered  where  the  special 
identifier  or  'key,'  mentioned  in  a  previous  chapter,  would 
best  fit.  Such  a  device  is  necessary  to  distinguish  between 
'pv'  sets  which  incidentally  are  identical,  although  they  may 
represent  different  objects,  or  to  detect  an  unwanted  redun¬ 
dancy.  Only  an  identifier  that  is  unique  to  every  single  ob¬ 
ject  can  meet  this  requirement.  However,  the  simple  arrangement 
of  the  objects  in  a  numerical  order  would  not  work,  since  by 
mistake  the  same  object  could  be  listed  under  different  numbers 
without  the  means  of  recognizing  the  error.  The  only  way  to 
solve  this  problem  is  by  introducing  a  key  value  that  can  only 
be  applied  in  connection  with  the  particular  object  it  defines, 
like  a  social  security  number  or  a  similar  characteristic 
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attribute.  We  adopt  this  technique  but  leave  the  selection 
of  the  proper  criterion  up  to  the  application  programmer. 

However,  it  is  considered  advantageous  always  to  define  the 
first  ' property_id '  of  a  class  as  the  key  element.  This  would 
allow  the  arrangement  of  the  objects  in  a  numerical  or  alpha¬ 
betical  order  with  regard  to  their  identifiers. 

Deletion  and  modification  have  one  thing  in  common.  The 
particular  object  must  be  retrieved  first  before  the  operation 
can  be  applied.  This  will  be  achieved  in  a  similar  way  as  for 
the  'selection'  operator.  The  'pv'  set  of  the  object  in  ques¬ 
tion  is  loaded  into  a  set  of  registers  and  the  appropriate 
class  is  identified.  Then  the  'pv'  set  representing  the  first 
object  of  the  class  is  loaded  into  a  separate  set  of  registers 
and  checked  for  identity.  As  soon  as  a  match  occurs  the  search 
stops.  In  the  case  of  a  modification  the  up-dated  'pv'  set 
will  be  stored  in  memory  and  the  pointers  are  adapted  to  the 
new  location.  For  a  deletion  operation  the  pointers  are  advanced 
and  the  "erased"  object  will  be  by-passed.  If  the  indicated  ob¬ 
ject  cannot  be  found  in  the  appropriate  class,  an  error  handling 
routine  is  activated  and  the  state  of  the  database  will  not 
be  changed. 


VII  . 


CONCLUSIONS 


Interface  standards  that  are  precise,  understandable  and 
enforceable  can  provide  a  way  to  improve  efforts  toward  porta¬ 
ble  software.  With  the  abstraction  of  a  database,  we  not  only 
extended  AM  by  adding  another  basic  resource  to  the  processor 
and  the  visual  display  device,  but  also  showed  a  way  to  reduce 
the  database  to  its  fundamental  properties.  Rather  than  being 
concerned  with  a  specific  data  definition  or  query  language, 
our  abstraction  of  a  database  is  intended  to  provide  a  uni¬ 
form,  abstract,  and  functional  interface  to  the  computing  system 

By  this  concept  the  application  programmer  retains  all  the 
freedom  he  needs  to  actually  implement  the  database  resource 
in  a  way  that  fits  his  purpose  best.  And  although  it  may  turn 
out  that  the  AM  machine  becomes  even  slower  as  the  result  of 
the  additional  data  types  we  introduced,  the  specified  axioms 
fully  describe  the  operations  in  a  precise,  unambiguous  and 
easily  understandable  manner,  thus  leaving  no  room  for  any 
different  interpretation  by  the  programmer. 

Based  on  the  principle  of  resource  abstraction,  the  AM 
specification  intensively  supports  a  strong  typing  such  that 
objects  of  a  given  type  can  not  take  other  values  than  the  ones 
appropriate  to  the  type,  and  no  operations  can  legally  be 
applied  to  an  object  which  are  not  defined  for  its  type.  All 
these  decisions  naturally  reduce  efficiency,  but  this  loss 
will  be  compensated  by  gains  in  clearness  and  accuracy. 


It  is  difficult  to  foresee  how  much  AM  can  be  modified  for 
efficiency  without  compromising  the  level  of  abstraction  pre- 

f 

sently  achieved.  To  test  for  resource  equivalence  or  to  prove 
the  correctness  of  implementations  of  resource  specifications 
is  a  nontrivial  matter,  and  this  problem  certainly  will  in¬ 
crease  with  every  change  attempted.  So,  for  the  near  future, 
it  seems  that  we  have  to  pay  the  price  for  implementing  in 
a  strictly  formal  way,  since  no  promising  theory  is  yet  known 
to  reduce  the  Targe  number  of  necessary  function  calls  within 
the  specification. 

Further  basic  resources  that  could  be  taken  into  consider¬ 
ation  for  a  possible  AM  extension  are  a  so-called  mouse  device 
with  properties  similar  to  the  joy  stick  cursor,  and  a 
keyboard . 
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APPENDIX  A 


A  GRAMMAR  FOR  ALGEBRAIC  SPECIFICATIONS 


P  ..  i 


abstraction ; 

(abstraction  spec) ? 


spec : 


( spechead I parmhead)  specbody  specend 


spechead ; 


nameblk  ' is ' 


parmhead ; 


nameblk  'parm'  specbody  'is' 


I  4 


specend : 


'end'  specname 


nameblk : 


'spec'  specname 


1  1 


specbody : 

extension?  specblk 
extension : 

extendblk  specblk  'end'  'extend'  ';' 
extendblk : 

'extend'  specnames  'with' 

specnames ; 

specname 

1 specnames  ' , '  specname 


I  « 


specblk ; 


useblk 

sortblk?  opblk  axiomblk? 


useblk ; 


mapping ; 


'use'  specname  '('  specname  ') '  mapping?  specblk 
' enduse ' 


'where'  eqivlist 


«  '  k  •  • 

L 


equivlist ; 

equivalence  ' ; ' 
i equivlist  equivalence  ';' 


•  -  *  •  •  .  *! 


equivalence : 

sortname  'is'  sortname 
1 opname  ' is '  opname 

sortblk : 

'sort'  sortnames 

sortnames : 

sortname  ' ; ' 

I sortnames  sortname  ' ; ' 

opblk : 

primblk?  dervblk?  hiddenblk? 

primblk : 

'primitive'  'op'  ops 

ops  : 

op  '  ;  ' 

I  ops  op  '  ;  ' 

op : 

opname  ';'  arglist?  sortname 

arglist : 

sortname 

I arglist  ','  sortname 
dervblk : 

dervops  dervdef 

dervops : 

'derived'  'op'  ops 

dervdef : 

'derived'  'def'  axioms 

hiddenblk : 

'hidden'  'op'  ops 

axiomblk : 

'axiom'  axioms 

axioms : 

axiom  ' ;  ' 

I  axioms  axiom  ' ;  ' 

axiom ; 

conditional 

1 ('for'  varlist  'in'  sortname)?  termexpr 


termexpr : 

factor 

I  multiplier?  opname  '('  factors  ')  ' 
factors : 

factor 

i factors  ' ,  '  factor 

factor : 

multiplier?  opname  '('  ')' 

[ freevar 

varlist : 

freevar 

1 varlist  ' , '  freevar 
multiplier : 

' [ '  positive_number  ' ] ' 
conditional : 

'if'  termexpr  meta_relop  termexpr  then  else?  'endif 
meta_relop : 

I  ^  I 

I  M  =  ' 

then: 

'then'  axioms 


else : 


'else'  axioms 


replace(X,S) 

"irref lexive (X,S)  ;  " 
with 

"X(i,i)  =  false  0 


replace (X, S) 

"symmetric (X,S) 
with 

"implies(X(i, j) ,X( j ,i) )  =  true();" 


replace (X,S) 

"antisymm.etric  (X,  S)  ;  " 
with 

"implies (and (X (i, j)  ,x(j,i) ), (i  ==  j ) )  =  true  ( ) ; " 


replace (S ,T) 

"idopers (S ,T) ; " 
with 

"startT:  -*■  S; 
nextT;S  S; 
prevT:S  S; 
eqS  :  S  ,  S  bool ;  " 


replace (S ,T) 

"idaxioms (S ,T) ; " 
with 

"prevS (startT 0 )  =  undef; 
prevS (nextS (i) )  =  i; 
if  i  !=  StartT 0  then 
nextS (prevS ( i) )  =  i; 
endif ; 

equivrel ( eqS , S ) ; " 


replace (S) 

"typingopers (S) ; " 
with 

"types :  ^  type ; 
atomofS:  val  ^  S ; 
valofS:  S  val;" 


replace (S) 

"typingaxioms (S) ;" 
with 

"whattype  ( valofS  ( t)  )  =  typeSO; 
atomof S (valof S ( t) )  =  t; 
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if  whattype(v)  =  types ( ) 

then  valof S (atomofS (v) )  =  v; 
else  atomofS (v)  =  undef; 
endif ;  " 


replace (S ,T) 

"relop (S,T) ; " 
with 

"applyrop(ST() ,vl,v2)  =  valofbool (TS (atomofS (vl) , 
atomofS ( v2) )  ) ; " 


replace (S) 

" isops (S ) ; " 
with 

"if  whattype(v)  =  types  () 

then  applybop (isS ( ) ,V)  =  valofbool ( true ()) ; 
else  applybop ( isS 0 ,v)  =  valofbool (false ())  ; 
endif; " 


replace (S ,T) 

"stateaxioms (S ,T) ; " 
with 

" fetchS (a , initam( ) )  =  undef; 

Stores (fetchS (a,q) ,a,q)  =  q; 
implies ( 

eqT (al ,a2) , 

fetchS (al , Stores (v,a2 ,q) )  =  v 
)  =  true  ( )  ; 
implies ( 

not (eqT (al ,a2) )  , 

f etchs (al , Stores (v,a2 ,q) )  =  fetch(al,q) 

)  =  true ( ) ;  " 

replace  /*  database  part  */ 

"crpidset" 
with 

"pidsetlist .makelst" 


replace 

"unpidset " 
with 

"pidsetlist .unis t" 


replace 

" intpidset " 
with 


pidsetlist . intis t 


replace 

"mempidset " 
with 

"pidsetlist .memblst" 


replace 

"crvalset " 
with 

" valsetlist .makelst" 


replace 

"unvalset" 

with 

"valsetlist . unlst" 


replace 

"intvalset" 

with 

"valsetlist . intlst " 


replace 

"memvalset " 
with 

"valsetlist .memblst" 


replace 

"getid" 

with 

"proplist . firs t 1st " 


replace 

"getvalset" 

with 

"proplist , restlst" 


replace 

"crprop" 

with 

"proplist . cat 1st" 

replace 

"crpropset" 

with 

"propsetlist .makenewlst" 


1 


replace 

"unpropset " 
with 

" propset list .unis t" 


replace 

"intpropset" 

with 

"propsetlist . intlst" 


replace 

"getidset " 
with 

"propsetlist . sof irstlst 


replace 

"mempropset " 
with 

" props  et 1 i s  t . memb 1st" 


replace 

"crpropval" 

with 

"pvallist . catlst" 


replace 

"getpid" 

with 

"pvallist. firstlst" 


replace 

"getval" 

with 

"pvallist. restlst" 


replace 

"memprop" 

with 

"pvallist .merablst" 


replace 

"crpvalset " 
with 


pvalsetlist .makenewlst 


replace 

"unpvalset" 

with 

"pvalsetlist .unlst" 


replace 

"intpvalset" 

with 

"pvalsetlist . intlst" 


replace 

"mempvalset " 
with 

"pvalsetlist .memblst" 


replace 

"mempset" 

with 

" pvalsetlist .memblst" 


replace 

"getpidset" 

with 

"pvalsetlist . sofirstlst" 


replace 

"crobj" 

with 

"objlist .makenewlst" 


replace 

"readob j " 
with 

"obj list .makenewlst" 


replace 

"haspval" 

with 

"obj list .memblst" 


replace 

"getopidset" 

with 


objlist. sofirstlst 


replace 

"getoval" 

with 

"ob j list . getlst" 


replace 

"crclass" 

with 

"classlist .makenewlst 


replace 

"unclass" 

with 

"classlist . unlst " 


replace 

"intclass" 

with 

"classlist. intlst" 


replace 

"memclass " 
with 

"classlist .memblst" 


replace 

"subclass  " 
with 

"classlist .memblst" 


replace 

"getcpidset " 
with 

"classlist .sofirstlst 


replace 

" insob j" 
with 

"classlist. cat 1st" 


replace 

"delobj" 

with 

"classlist. deist" 


replace 

"crdb" 

with 

"dblist .makenewlst 


replace 

"memdb" 

with 

" db 1 i s  t . memb 1st" 


replace 

"insclass" 

with 

"dblist. catlst" 


replace 

"delclass" 

with 

"dblist .deist" 


replace 

"retclass" 

with 

"dblist. intlst" 


replace 

"retobj  " 
with 

"dblist . retob  jlst" 


replace 

"getbdbidset " 
with 

"dblist . sof irstlst 


replace 

"modob j " 
with 


dblist. modlst 


spec  boolean 
is 

sort 

bool  ; 
primitive 
op 

true:  ^  bool; 
false:  bool; 

not:  bool  ^  bool; 
and;  bool, bool  -»■  bool; 
derived 
op 

or:  bool, bool  ^  bool; 
implies:  bool, bool  bool; 
derived 
def 

or{bl,b2)  =  not (and (not (bl) , not (b2) )  ); 
implies (bl ,b2)  =  not (and (bl , not (b2) )  ); 
axiom 

false  0  =  not(true()); 
not (not (b) )  =  b ; 
and (true ( ) ,b)  =b; 
and  (  false  ()  ,b)  =  falseO; 
commutative (and, bool) ; 
end  boolean; 


spec  natural 
is 

extend 

boolean 

with 

sort 
nat ; 

primitive 

op 

zeronat;  nat; 
prednat:  nat  nat; 
succnat;  nat  -*■  nat; 
sumnat:  nat, nat  ■*  nat; 
subnat:  nat, nat  ^  nat; 
mltnat:  nat,  nat  nat; 
divnat :  nat,  nat  nat; 
eqnat :  nat, nat  ^  bool; 
gtnat:  nat, nat  -*■  bool; 
derived" 
op 

Itnat;  nat,  nat  -►  bool; 
genat:  nat,  nat  ->•  bool; 
lenat:  nat, nat  ->■  bool; 
nenat :  nat,  nat  -*•  bool; 


/*  zero  *  / 

/*  predecessor  */ 

/*  successor  */ 

/*  addition  */ 

/*  subtraction  */ 

/*  multiplication  */ 
/*  division  */ 

/*  equal  */ 

/*  greater  than  */ 


/*  less  than  */ 

/*  greater  or  equal  */ 
/*  less  or  equal  */ 

/*  not  equal  */ 


derived" 

def 

ltnat(n,m)  =  not (or (gtnat (n ,m) , eqnat (n ,m) )  ); 
genat(n,m)  =  not ( Itnat (n,m) ) ; 
lenat(n,m)  =  not  (gtnat  (n,in)  )  ; 
nenat(n,m)  =  not (eqnat (n,m) ) ; 
axiom 

prednat ( zeronat ( ) )  =  undef ; 
prednat ( succnat (n) )  =  n; 
succnat (prednat (n) )  =  n; 
sumnat (n, zeronat 0 )  =  n; 

sumnat (n, succnat (m) )  =  succnat (sumnat (n,m) ) ; 
subnat (n , zeronat 0 )  =  n; 
if  gtnat(n,m)  =  trueO 
then 

subnat (n , succnat (m) )  =  prednat (subnat (n,m) ) 
else 

subnat (n, succnat (m) )  =  undef; 
endif ; 

mltnat (x, zeronat 0 )  =  zeronat (); 
ml tnat (x, succnat ( zeronat 0 )  )  =  x; 
mltnat(x,y)  =  sumnat (x, mltnat (x, prednat (y) )  ); 

if  y  =  zeronat 0 
then 

divnat(x,y)  =  undef; 
else  if  ltnat(x,y)  =  true() 
then 

divnat(x,y)  =  zeronatO; 
else 

divnat(x,y)  =  sumnat ( 
succnat ( zeronat ( ) ) , 
divnat (subnat (x,y) ,y) 

)  ; 

endif ; 
endif  ; 

eqnat(n,m)  =  eqnat(succnat(n),succnat(m)); 
gtnat ( succnat (n) ,n)  =  true ( ) ; 
equivrel (eqnat, nat)  ; 
irreflexive (gtnat ,nat)  ; 
irreflexive ( Itnat , nat)  ; 
transitive (gtnat , nat) ; 
transitive ( Itnat , nat)  ; 
transitive (genat , nat)  ; 
transitive ( lenat , nat)  ; 
antisymmetric (genat , nat)  ; 
antisymmetric (lenat , nat) ; 
symmetric (nenat , nat)  ; 
commutative (sumnat, nat)  ; 
commutative vmltnat , nat)  ; 
associative (sumnat, nat) ; 
associative (mltnat , nat)  ; 
end  extend; 
end  natural; 


spec  integer 
is 

extend 

boolean, 

nat 

with 

sort 
int  ; 

primitive 

op 

zeroint:  -►  int; 

ntoi:  nat  ^  int;  /*  nat  to  int  */ 

iton:  int  ->■  nat;  /*  int  to  nat  */ 

absint:  int  -*•  int;  /*  absolute  value  */ 

predint;  int  -►  int; 

succint:  int  ^  int; 

sumint:  int, int  -►  int; 

subint:  int, int  ^  int; 

mltint:  int,  int  int; 

divint:  int,  int  int; 

modint:  int,  int  int;  /*  modulo  */ 

eqint:  int, int  ^  bool; 
gtint:  int,  int  -*■  bool; 
derived 
op 

Itint;  int, int  ^  bool; 
geint:  int,  int  bool; 
leint;  int,  int  bool; 
neint:  5iit:,int  -»■  bool; 
derived 
def 

ltint(n,m)  =  not (or (gtint (n ,m) , eqint (n,m) )  ); 
geint(n,m)  =  not ( Itint (n ,m) ) ; 
leint(n,m)  =  not (gtint (n,m) ) ; 
neint(n,m)  =  not (eqint (n ,m) ) ; 
axiom 

predint (succint (n) )  =  n; 
succint (predint (x) )  =  x; 
ntoi  ( zeronat  ( )  )  =  zerointO; 

ntoi (succnat (n) )  =  sumint (succint ( zeroint ()) , 

ntoi (n) ) ; 

iton ( zeroint 0 )  =  zeronat (); 
if  Itint (x , zeroint 0 )  =  true ( ) 
then 

iton(x)  =  undef; 
else 

iton (succint (x) )  =  sumnat (succnat ( zeronat) , 

iton (x) ) ; 


endif ; 


if  Itint  (x,  zeroint  0  )  =  trueO 
then 

absint(x)  =  subint ( zeroint () ,x) ; 
else 

absint(x)  =  x; 
endif ; 

sumint (n , zeroint 0 )  =  n; 

sumint (n, succint (m) )  =  succint (sumint (n ,m) ) ; 
subint (x, zeronat 0 )  =  x; 

subint (x, succnat (y) )  =  predint(subint(x,y)); 

mltint  (x,  zeroint  ()  )  =  zerointO; 

ml tint (x , succint ( zeroint 0 )  )  =  x; 

mltint(x,y)  =  sumint (x , mltint (x , predint (y) )  ) ; 

if  y  =  zerointO 

then 

divint(x,y)  =  undef; 

else  if  Itint (absint (x) ,absint (y) )  =  true() 
then 

divint(x,y)  =  zerointO; 
else  if  or( 
and  ( 

gtint (x, zeroint 0 )  , 
gtint (y , zeroint ( ) ) 

)  , 

and  ( 

Itint (x , zeroint  0 )  , 

Itint (y , zeroint  ( ) ) 

) 

)  =  trueO 
then 

divint(x,y)  =  sumint( 
succint ( zeroint ( ) ) , 
divint (subint (x,y) ,y) 

)  ; 

else 

divint(x,y)  =  sumint( 
predint ( zeroint ( ) ) , 
divint ( sumint (x ,y) ,y) 

)  ; 

endif ; 
endif; 
endif ; 

if  gtint (m, zeroint ()  )  =  true () 
then 

if  Itint (n , zeroint 0 )  =  true () 
then 

modint(n,m)  =  modint  ( sxmiint  (n  ,m)  ,m)  ; 
else 

modint(n,m)  =  subnat (n,mltnat (m, divint (n,m) )  ) 

endif ; 
else 

modint(n,m)  =  undef; 
endif ; 


eqint(x,y)  =  eqint (succint (x)  , succint (y) )  ); 

gtint  (succint  (n)  ,n)  =  trueO; 
equivrel (eqint , int) ; 
irreflexive (gtint , int) ; 
irref lexive ( Iting , int) ; 
transitive (gtint , int) ; 
transitive (Itint, int) ; 
transitive (geint , int) ; 
transitive ( leint , int) ; 
antisymmetric (geint , int) ; 
antisymmetric (leint , int)  ; 
symmetric (neint , int)  ; 
commutative ( sumint , int) ; 
commutative (mltint, int)  ; 
associative ( sumint , int)  ; 
associative (mltint , int) ; 
end  extend; 
end  integer; 


spec  character 
is 

extend 

boolean 

with 


sort 

char ; 
primitive 
op 


A' , 'B' 
a  '  , 'b  ' 

1 ' , 

1  p  1 

f  Vx  /  •  «  « 

/  '  c  *  ,  .  •  • 

,  'Z  '  :  ^ 

,  '  z  '  :  -»• 

char ; 
char; 

1  1  r  1 

/  a  / 

1  *  I 

9 

'(’,')’: 

-*■  char 

—  *  1  1 
/ 

1  X  *  »  —  « 

1  f  1  / 

/  t 

char 

II  1  M  1 

/ 

»  .  t  1  .  1 

f  •  t  t 

1  1  f 

t  t  9  9 

■>  '  , 

char 

1  1  II, 

1 '  !  *  2  * 

^  char; 

'  ,  ’7’  , 

8'  , 

'9 ' ,  '0  '  : 

-*•  char 

NUL:  ->■  char; 
SOH  :  ->  char; 
STX:  char; 

ETX:  char; 

EOT:  ^  char; 
ENQ:  ->-  char; 
ACK:  char; 

BEL:  ->■  char; 
BS :  ->■  char; 
HT:  -*■  char; 
LF :  char  ; 

VT:  ->  char; 
FF :  ->■  char; 
CR:  -*■  char; 
SO:  char; 

SI:  char; 

OLE:  char; 


DCl :  -*■  char; 
DC2  :  ->■  char  ; 
DCS:  char; 

DC 4:  ^  char; 
NAK:  char; 

SYN:  ^  char; 
ETB:  char; 

CAN :  char  ; 

EM:  ->■  char; 
SUB:  -*■  char; 
ESC:  -*■  char; 
FS :  ^  char; 
GS :  ^  char; 
RS :  -+  char; 
US:  char; 

SP:  -<■  char; 


DEL:  char; 

eqchar:  char, char  bool; 
gtchar:  char,  char  -*■  bool; 
derived 
op 


Itchar : 
gechar : 
lechar : 
nechar : 
derived 
def 


char, char  -►  bool; 
char, char  ^  bool; 
char, char  ^  bool; 
char, char  ^  bool; 


ltchar(n,m)  =  not (or (gtchar (n,m) , eqchar (n,m) ) 
gechar(n,m)  =  not (ltchar(n,m) ) ; 
lechar(n,m)  =  not (gtchar (n,m) ) ; 
nechar(n,m)  =  not (eqchar (n ,m) ) ; 
axiom 


gtchar ( ' DEL ' , ' ' 

')  =  trueO 

gtchar ( ' '  ' 

=  true ( ) ; 

gtchar ( ' } ' 

.  '  1  ') 

=  true ( ) ; 

gtchar ( ' | ' 

=  trueO  ; 

gtchar ( ' {  ' 

,  'z') 

=  true ( ) ; 

gtchar ( ' z  ' 

f  *  m  *  f 

' a ' )  =  true 

gtchar ( ' a ' 

') 

=  true ( )  ; 

gtchar('  ' 

,  '  ') 

=  true ( )  ; 

gtchar ( '  ' 

=  trueO  ; 

gtchar ( ' " ' 

=  true ( )  ; 

gtchar ( ' ] ' 

=  true ( )  ; 

gtchar ( '  '  , 

'  [') 

=  true ( ) ; 

gtchar (  '  [  ' 

,  'Z') 

=  true ( ) ; 

gtchar ( ' Z ' 

r  •  •  •  f 

'A')  =  true 

gtchar ( ' A' 

=  true ( ) ; 

gtchar  (  '  (a  ' 

, '?’) 

=  true ( ) ; 

gtchar ( ' ? ' 

=  trueO  ; 

gtchar ( ' > ' 

=  true ( ) ; 

gtchar ( ' = ' 

,  ’<•) 

=  trueO  ; 

gtchar ( ' < ' 

,  ' ;  • ) 

=  true ( ) ; 

L.-,J 
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gtchar =  true ( ) ; 
gtchar 9 ' )  =  true ( ) ; 
gtchar ('9',...,'0')  =  true ( ) 
gtchar  (' 0 )  =  trueO; 
gtchar  ('/' f '•' )  =  trueO; 
gtchar =  true ( ) ; 
gtchar  )  =  trueO; 

gtchar =  true ( ) ; 
gtchar  )  =  trueO; 

gtchar =  true ( ) ; 
gtchar =  true ( ) ; 
gtchar  (  '  =  trueO  ; 

gtchar =  true ( ) ; 
gtchar =  true ( ) ; 
gtchar =  true ( ) ; 
gtchar =  true ( ) ; 
gtchar =  true ( ) ; 
gtchar =  true ( ) ; 
gtchar  SP)  =  trueO; 

gtchar  (SP ,  US)  =  trueO; 
gtchar  (US  ,  RS)  =  trueO; 
gtchar  (RS  ,GS)  =  trueO; 
gtchar(GS,FS)  =  trueO; 
gtchar (FS , ESC)  =  true(); 
gtchar (ESC, SUB)  =  true(); 
gtchar (SUB , EM)  = . true ( ) ; 
gtchar  (EM, CAN)  =  trueO; 
gtchar  (CAN,  ETB)  =  trueO; 
gtchar  (ETB  ,  SYN)  =  trueO; 
gtchar (SYN ,NAK)  =  true ( ) ; 
gtchar  (NAK,DC4)  =  trueO; 
gtchar  (DC4  ,DC3)  =  trueO; 
gtchar  (DC3  ,  DC2 )  =  trueO; 
gtchar  (DC2  ,DC1)  =  trueO; 
gtchar  (DCl , OLE)  =  trueO; 
gtchar (OLE , SI)  =  true(); 
gtchar (SI , SO)  =  true(); 
gtchar (SO, CR)  =  true ( ) ; 
gtchar (CR, FF)  =  true () ; 
gtchar (FF ,VT)  =  true(); 
gtchar (VT ,LF)  =  true(); 
gtchar (LF ,HT)  =  true ( ) ; 
gtchar (HT,BS)  =  true(); 
gtchar  (BS  ,  BEL)  =  trueO; 
gtchar (BEL ,ACK)  =  true ( ) ; 
gtchar  (ACK,ENQ)  =  trueO; 
gtchar (ENQ, EOT)  =  true(); 
gtchar  (EOT,  ETX)  =  trueO; 
gtchar  (ETX,STX)  =  trueO; 
gtchar  (STX,SOH)  =  trueO; 
gtchar  (SOH,NUL)  =  trueO; 
equivrel (eqchar ,char)  ; 


irref lexive (gtchar ,char) ; 
irref lexive (Itchar , char) ; 
transitive(gtchar,char) ; 
transitive (Itchar, char)  ; 
transitive (gechar, char) ; 
transitive (lechar, char) ; 
antisymmetric (gechar , char) ; 
antisymmetric (lechar, char) ; 
symmetric (nechar , char) ; 
end  extend; 
end  character; 


spec  string 
parm 

extend 

boolean 

with 

sort 

Im; 

primitive 

op 

eqlm;  lm,lm 
gtlm:  lm,lm 
derived 


bool ; 
bool ; 


Itlm:  lm,lm 
gelm:  lm,lm 
lelm:  lm,lm 
nelm:  lm,lm 
derived 
def 

ltlm(n,m)  = 
gelm(n,m)  = 
lelm(n,m)  = 
nelm(n,m)  = 


bool  ; 
bool ; 
bool  ; 
bool ; 


not (or (gtlm (n,m) , eqlm (n ,m) )  ) 
not (Itlm (n ,m) ) ; 


not (gtlm(n,m) ) 
not (eqlm(n,m) ) 


equivrel (eqlm, Im) ; 
irref lexive (gtlm, Im) ; 
irref lexive ( Itlm, Im) ; 
transitive (gtlm, Im) ; 
transitive ( Itlm, Im) ; 
transitive (gelm, Im) ; 
transitive (lelm , Im) ; 
antisymmetric (gelm, Im) ; 
antisymmetric ( lelm, Im) ; 
symmetric (nelm, Im) ; 
end  extend; 


extend 

natural 

boolean 


primitive 

op 

nullstr:  ->■  str;  /*  null  string  */ 

makestr:  Im  -»■  str;  /*  make  */ 

lenstr:  str  nat;  /*  string  length  */ 

headstr:  str  Im;  /*  string  head  */ 

tailstr:  str  ^  str;  /*  string  tail  */ 

catstr:  str,  str  -*■  str;  /*  concatenation  */ 

eqstr:  str, str  ^  bool; 
gtstr:  str, str  ^  bool; 
derived 
op 

Itstr:  str,  str  bool; 
gestr:  str, str  ^  bool; 
lestr:  str,  str  ->■  bool; 
nestr:  str, str  ^  bool; 
derived 
def 

ltstr(n,m)  =  not (or (gtstr ( n ,m) , eqstr ( n ,m) )  ); 

gestr(n,m)  =  not ( Itstr (n ,m) ) ; 
lestr (n,m)  =  not(gtstr(n,m)); 
nestr (n,m)  =  not (eqstr (n,m) ) ; 
axiom 

lenstr  (nullstr)  =  zeronatO; 

lenstr (makestr (1) )  =  succnat (zeronat ( ) ) ; 

lenstr (catstr (si ,s2) )  =  sumnat ( lenstr ( si) , 

lenstr (s2) ) ; 

headstr (makestr (1) )  =  1; 

tailstr (makestr ( 1) )  =  nullstr; 

headstr (cats-r (makestr ( 1) , s) )  =  1; 

tailstr (catstr (makestr (1) , s2) )  =  s2; 

headstr (nullstr)  =  undef; 

tailstr (nulls tr)  =  nullstr; 

catstr (catstr (si , s2) , s3)  =  catstr(sl, 

catstr ( s2 , s3) ) ; 
catstr (nullstr ,s)  =  catstr (s , nullstr)  =  s; 
implies(eqlm(ll,12) , eqstr (makestr ( 11 ) , 

makestr(12))  )  =  true ( ) ; 

implies(gtlm(ll,12) , gtstr (makestr ( 11) , 

makestr(12))  )  =  true(); 
gtnat ( lenstr (makestr ( 1) ) , lenstr (nullstr) ) 

=  true ( )  ; 

implies (gtnat ( lenstr ( si ) , lenstr (s2) ) , 

gtstr  (si, s2)  )  =  trueO; 
if  lenstr(sl)!  =  zeronatO 
then 

gtnat ( lenstr (catstr (si , s2) , lenstr ( s2) ) 

=  true ( ) ; 


eqnat ( lenstr (catstr ( si , s2)  , lenstr { s2) ) 

=  true  0 ; 

endif; 

equivrel (eqstr , str)  ; 
irreflexive (gtstr,str) ; 
irref lexive ( Itstr , str)  ; 
transitive (gtstr, str) ; 
transitive ( Itstr , str)  ; 
transitive (gestr, str)  ; 
transitive { lestr , str) ; 
antisymmetric (gestr , str)  ; 
antisymmetric (lestr , str)  ; 
symmetric (nestr, str)  ; 
end  extend ; 
end  string; 


spec  str.chartype 
is 

extend 

character 

with 

use 

string (character) 
where 

char  is  Im; 
eqchar  is  eqlm; 
gtchar  is  gtlm; 
Itchar  is  Itlm; 
gechar  is  gelm; 
lechar  is  lelm; 
nechar  is  nelm; 
end  extend; 
end  str.chartype; 


spec  intensity  /*  display  part  */ 

is 

extend 

boolean 

with 

sort 

intens ; 
primitive 
op 

minintens:  ^  intens;  /*  minimum  intensity  */ 

maxintens:  -*■  intens;  /*  maximum  intensity  */ 

nullintens:  ^  intens;  /*  null  intensity  */ 

predintens:  intens  -*■  intens; 


succintens :  intens  -*•  intens; 
sumintens:  intens  , intens  intens; 
subintens:  intens  ,  intens  -*■  intens; 
eqintens:  intens  ,  intens  ->•  bool; 
gtintens :  intens , intens  ^  bool; 
derived 
op 

Itintens:  intens  , intens  -*■  bool; 
geintens  :  intens  ,  intens  -+■  bool; 
leintens  :  intens , intens  bool; 

neintens:  intens , intens  -*■  bool; 
derived 
def 

Itintens (n ,m)  =  not {or(gtintens (n,m) , eqintens (n,m) )  ) 

geintens  (n ,m)  =  not  (Itintens  (n,in)  )  ; 
leintens  (n  ,m)  =  not  (gtintens  (n,in)  )  ; 
neintens (n,m)  =  not (eqintens (n ,m) ) ; 
axiom 

predintens (minintens ( ) )  =  undef; 

predintens (nullintens ( ) )  =  undef; 

succintens (maxintens 0 )  =  undef; 

succintens (nullintens 0 )  =  undef; 

sumintens ( i . nullintens 0 )  =  undef; 

subintens ( i , nullintens 0 )  =  undef; 

maxintens 0  =  [NUMINTENS] succintens (minintens () ) 

sumintens (i ,minintens 0 )  =  i; 

subintens ( i ,minintens 0 )  =  i; 

sumintens (i,succintens (j) )  =  succintens 

(sumintens (i , j ) ) ; 

if  gtintens  ( i  ,  j  )  =  trueO 
then 

subintens (i , succintens ( j  )  )  = 

predintens ( subintens ( i , j )) ; 

else 

subintens ( i , succintens ( j ) )  =  undef; 
endif; 

eqintens ( i , j )  =  eqintens (succintens ( i) , 

succintens ( j ) ) ; 

eqintens ( i , j  )  =  eqintens (predintens ( i)  , 

predintens (j)); 

eqintens  ( i  ,  succintens  (predintens  ( i)  )  )  =  trueO; 
eqintens  ( i  ,  predintens  (succintens  ( i)  )  )  =  trueO; 
if  or  ( 

eqintens ( i , nullintens ( ) ) , 
eqintens ( j , nullintens ()  ) 

)  =  trueO 
then 

gtintens (i , j )  =  undef; 
endif 

gtintens  (succintens  (i)  ,  i)  =  trueO; 
equivrel (eqintens , intens)  ; 


irref lexive (gtintens , intens) ; 
irreflexive (Itintens , intens) ; 
transitive (gtintens , intens)  ; 
transitive (Itintens, intens) ; 
transitive (geintens , intens)  ; 
transitive ( leintens , intens) ; 
antisymmetric (geintens , intens) ; 
antisymmetric (leintens, intens)  ; 
symmetric (neintens , intens) ; 
commutative (sumintens , intens) ; 
associative (sumintens , intens) ; 
end  extend; 
end  intensity; 


spec  pointcolor 
is 

extend 

boolean 

intensity 

with 

sort 

color; 

primitive 

op 

nullcolor:  ->■  color;  /*  null  color  */ 

redcompnt :  color  ->■  intens;  /*  red  component  */ 

grncompnt:  color  -*•  intens;  /*  green  component  */ 

blucompnt:  color  -*■  intens;  /*  blue  component  */ 

eqcolor:  color, color  ->■  bool;  /*  equal  color  */ 
def color:  intens , intens , intens  color; 

/*  define  color  */ 

axiom 

redcompnt (nullcolor 0 )  =  nullintens ( ) ; 
grncompnt (nullcolor 0 )  =  nullintens () ; 
blucompnt (nullcolor 0 )  =  nullintens () ; 
if  and( 
or( 

or  ( 

eqintens ( il , nullintens ( )  ) , 
eqintens ( i2 , nullintens ( ) ) 

)  , 

eqintens ( i3 , nullintens ( )  ) 

)  , 
or( 

or  ( 

not (eqintens (il , nullintens 0 )  ), 
not (eqintens (i2 , nullintens 0 )  ) 

)  , 

not ( eqintens ( i3 , nullintens ( ) )  ) 


) 


then 

defcolor(il,i2,i3) )  =  undef; 
else 

redcompnt  (defcolordl, 12,13)  )  =  11 
grncompnt  (defcolordl, 12,13)  )  =  12 
blucompnt(defcolordl, 12,13)  )  =  13 
endlf ; 
eqcolor (cl,c2)  =  and( 
and  ( 

eqintens (redcompnt (cl) , redcompnt (c2) ) , 
eqlntens (grncompnt (cl) , grncompnt (c2) ) 


) 


) 

eqlntens (blucompnt (cl) ,blucompnt (c2) ) 


equlvrel (eqcolor, color) ; 
end  extend ; 
end  polntcolor; 


I  I 


i  4 


spec  point 
Is 

extend 

boolean , 
natural , 
Integer 
with 
sort 
pnt; 

primitive 
op 


lepnt:  pnt, pnt 


Inline  */ 

bool;  /*  left  &  below, 

or  left  Inline  or  below 
Inline  */ 

lnt,lnt,pnt  ->■  pnt;  /*  point  offset  */ 


of fsetpnt : 
axiom 

xcorddocpnt  (11,12)  )  =  11; 
ycord(locpnt(ll,12) )  =  12; 
eqpnt(pl,p2)  =  and( 

eqlnt (xcord (pi) ,xcord(p2) ) 
eqlnt (ycord (pi) ,ycord(p2)) 
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.  'V*"* 


xcord: 

pnt  ->■  Int; 

/* 

X  coordinate  */ 

ycord: 

pnt  ^  Int ; 

/* 

y  coordinate  */ 

locpnt 

:  Int,  Int  -*■  pnt; 

/* 

point  location  */ 

LT^»“o  * 

eqpnt : 

pnt, pnt  ^  bool; 

/* 

equal  point  */ 

gtpnt : 

pnt, pnt  ^  bool; 

/* 

right  &  above  */ 

Itpnt : 

pnt, pnt  -»■  bool; 

/* 

left  &  below  */ 

•  *  ^  ■*  *  ^ 

gepnt : 

pnt, pnt  bool; 

/* 

right  &  above, 

•  j*  *  "j*  *•  i 

^  ^  ^  T.  • 

*  V 

or 

right  Inline  or  above 

r.y.j 


4 


-4 


>K;v: 


gtpnt(pl,p2)  =  and( 

gtint (xcord (pi) ,xcord(p2) ) , 
gtint (ycord (pi) ,ycord(p2) ) 

)  ; 

ltpnt(pl,p2)  =  and ( 

Itint (xcord (pi) , xcord (p2) ) , 

Itint (ycord (pi) , ycord (p2) ) 

)  ; 

gepnt(pl,p2)  =  and( 
or  ( 

gtint (xcord (pi) ,xcord(p2) ) , 
eqint (xcord (pi) ,xcord(p2) ) 

)  , 

or  ( 

gtint (ycord (pi) , ycord (p2) ) , 
eqint (ycord (pi) , ycord (p2) ) 

) 

)  ;  . 

Iepnt(pl,p2)  =  and( 
or  ( 

Itint (xcord (pi) ,xcord(p2) ) , 
eqint (xcord (pi) , xcord (p2) ) 

)  , 

or  ( 

Itint (ycord (pi) ,ycord(p2) ) , 
eqint (ycord (pi) , ycord (p2) ) 

) 

)  ; 

if  X  =  zerointC) 
then 

xcord (offsetpnt (x,y,p) )  =  xcord (p); 
else  if  gtint (x , zeroint 0 )  =  true ( ) 
then 

xcord (of fsetpnt (x,y,p) )  =  succint (xcord 
(of fsetpnt (predint (x) ,y ,p) )  ) 

else 

xcord (offsetpnt (x,y,p) )  =  predint (xcord 
(offsetpnt(succint(x) ,y,p)  )  ) 

endif ; 
endif ; 

if  y  =  zeroint 0 
then 

ycord (of fsetpnt (x ,y, p) )  =  ycord(p2); 
else  if  gtint (y , zerint () )  =  true ( ) 
then 

ycord (offsetpnt (x,y,p) )  =  succint (ycord 
(off setpnt (x, predint (y) ,p) )  ) 

else 

ycord (offsetpnt (x,y,p) )  =  predint (ycord 
(off setpnt (x, succint (y)  ,p)  )  ) 

endif ; 
endif ; 
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equivrel (eqpnt , pnt)  ; 
ref lexive (gepnt ,pnt) ; 
reflexive (lepnt, pnt)  ; 
irreflexive (gtpnt ,pnt)  ; 
irref lexive (Itpnt , pnt)  ; 
transitive (gtpnt , pnt)  ; 
transitive (Itpnt , pnt)  ; 
transitive (gepnt , pnt) ; 
transitive (lepnt, pnt)  ; 
end  extend; 
end  point; 

spec  rectangle 
is 

extend 

boolean , 
integer, 
point 
with 

sort 

ret  ; 

primitve 

op 

origin:  ret  ->■  pnt;  /*  lower  left 

corner  */ 

corner:  ret  ->■  pnt;  /*  upper  right 

corner  */ 

xdimret ;  ret  -»■  int;  /*  x  dimension  */ 

ydimret:  ret  '»•  int;  /*  y  dimension  */ 

area:  pnt, pnt  ret;  /*  define  ret  */ 

inret:  pnt, ret  bool;  /*  pnt  inside  ret 

test  */ 

disjrct:  ret, ret  -►  bool;  /*  disjoint  rets  */ 

intsetret:  ret, ret  -*■  ret;  /*  ret  intersection  */ 

putret:  pnt, ret  •+  ret;  /*  put  ret  at 

location  */ 

shiftret:  int,  int,  ret  -»•  ret;  /*  shift  ret  */ 
axiom 

if  Itint (xcord (p2) , xcord (pi) )  =  true ( ) 
then 

xcord (origin (area (pi, p2) )  )  =  xcord(p2); 

else 

xcord (origin (area (pi ,p2) )  )  =  xcord(pl); 
endif ; 

if  Itint  (ycord  (p2)  ,ycord  (pi)  )  =  trueO 
then 

ycord (origin (area (pi ,p2) )  )  =  ycord(p2); 
else 

ycord (origin (area (pi ,p2) )  )  =  ycord(pl); 

endif ; 
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if  gtint  (xcord (pi)  ,xcord (p2)  )  =  true(.) 
then 

xcord (corner (area (pi, p2) )  )  =  xcord (pi) 

else 

xcord(corner (area(pl,p2) )  )  =  xcord(p2) 

endif ; 

if  gtint (ycord(pl)  ,ycord(p2)  ).  =  trueC) 
then 

ycord(.corner(area(pl,p2)  )  )  =  ycord(.pl) 
else 

ycord(corner (area(pl,p2) )  )  =  ycord(p2) 

endif ; 

inrct(p,r)  =  and( 

gepnt(p,origin(r) )  , 
lepnt ( p , corner ( r)  ) 

)  ; 

dis jrct ( rl , r2)  = 
not (or ( 
or  ( 

inrct (origin (r2)  ,rl)  , 
inrct (corner (r2) ,rl) 

)  , 

or  ( 

inrct ( 

locpnt (xcord (origin (r2) )  , 

ycord ( corner ( r2 ) )  ), 
rl 

)  , 

inrct ( 

locpnt (xcord (corner (r2) ) , 

ycord (origin (r2) )  ), 
rl 

) 

) 

) )  ; 

if  dis  jrct  (rl ,  r2)  =  trueO 
then 

intsctrct (rl , r2)  =  undef; 
else 

inrct (p , intsctrct (rl , r2)  =  and ( 
inrct (p , rl) , 
inrct (p , r2) 

)  ; 

endif ; 

shif tret (x ,y , r)  =  area( 

offsetpnt (x,y ,origin(r) ) , 
offsetpnt (x,y, corner (r) ) 

)  ; 

putrct(p,r)  =  area( 

P/ 

of f setpnt (xdimret (r) ,ydimrct(r) ,p) 


xdimrct(r)  =  subint{ 
xcord (origin (r) ) , 
xcord (corner ( r) ) 

)  ; 

ydiinrct(r)  =  subint( 
ycord (origin (r)  )  , 
ycord (corner (r)  ) 

)  ; 

end  extend; 
end  rectangle; 


spec  image forii'. 
is 

extend 

boolean , 
pointcolor , 
point , 
rectangle 
with 

sort 

form; 

primitive 

op 

initform;  ret  ^  form;  /*  initialize  form  */ 

farea:  form  ret;  /*  ret  area  of 

form  */ 

getcolor:  pnt ,  form  ->■  color;  /*  get  pnt  color  */ 

filiform;  color,  form  ->■  color;  /*  fill  form  */ 

setcolor:  pnt , color , form  form; 

/*  set  pnt  color  */ 

y***************************************** 

*  invform  -  inverse  form 

*  given  color  A,  color  B,  form  F 

*  map  F  foreground  colors  to  A 

*  map  F  background  to  B 

*  / 

invform;  color , color,  form  -*•  form; 
axiom 

farea ( initform( r) )  =  r; 

getcolor (p , initform (r) )  =  nullcolor(); 
if  inret (p , farea ( f) )  =  true ( ) 

then  getcolor (p , setcolor (p , c , f) )  =  c; 
else  getcolor (p , f)  =  nullcolor(); 
endif ; 

if  inret (p, farea (f) )  =  true ( )  then 
getcolor (p , fillform(c , f) )  =  c; 
endif ; 

if  inret  (p ,  farea  ( f)  )  =  falseO  then 
setcolor (p , c , f)  =  undef; 
endif ; 


if  inrct (p, farea (f ) )  =  true ( )  then 
if  getcolor  (p ,  f )  =  nullcolorO 
then 

getcolor (p,invforin(cl,c2,f )  )  =  c2; 
else 

getcolor (p, invform (cl , c2 , f) )  =  cl; 
endif ; 
endif ; 
end  extend; 
end  imageforin; 


spec  iconfont 
is 

extend 

boolean , 
natural , 
pointcolor , 
rectangle , 
imageform, 
pntblktrans 
with 
sort 

font  ; 
primitive 
op 

initfont:  ret  ^  font;  /*  initialize  font  */ 

rctfont;  font  ret;  /*  ret  of  font 

icons  */ 

lenfont:  font  -*•  nat;  /*  number  of  icons 

in  font  */ 

spmap:  rct,pnt  ^  pnt;  /*  map  spot  (font 

loc)  to  pnt  */ 

psmap:  ret, pnt  ->■  pnt;  /*  map  pnt  to  spot 

(font  loc)  */ 

infont;  nat, font  -*•  bool;  /*  for  given  index, 

does  font  have  icon  */ 

delfont;  nat,  font  -*•  font;  /*  delete  icon 

from  font  */ 

getfont:  form, nat , font  font;  /*  put  icon  into 

font  */ 

offsetfont:  int , int , font , pnt  ^  pnt; 

/*  offset  in 

multiples  of  font  rets  */ 

axiom 

rctfont ( initfont (r) )  =  r; 

lenfont  ( initfont  (r)  )  =  zeronatO; 

spmap (r,p)  =  locpnt( 

mltint (xcord (p) ,xdimrct(r) ) , 
mltint (ycord (p) ,ydimrct(r)  ) 


psmap(r,p)  =  locpnt( 

divint (xcord (p) ,xdimrct (r) ) , 
divint (ycord (p) ,ydimrct(r)) 

)  ; 

infont ( id , initfont (r) )  =  false(); 
infont  { id ,  delfont  ( id  ,  f  t)  )  =  falseO; 
infont  (id,  setfont  ( f ,  id,  f  t)  )  =  trueO; 
if  and( 

eqint (xdimrct (rctfont (ft) ) ,xdimrct (farea (f ) )  ) , 
eqint (ydimrct (rctfont (ft) ) ,ydimrct (farea (f ) )  ) 

)  =  false() 
then 

setfont ( f , id , ft)  =  undef ; 
endif ; 

if  infont ( id , ft )  =  true ( ) 
then 

lenfont ( setfont ( f , id , ft ) )  =  lenfont ( f t ) ; 
else 

lenfont (setfont (f , id , ft ) )  =  succnat ( lenfont ( ft ) ) 
endif ; 

if  infont ( id, ft)  =  true() 
then 

lenfont (delfont (id, ft) )  =  prednat ( lenfont ( ft )) ; 
else 

lenfont (delfont (id, ft) )  =  lenfont ( ft ) ; 
endif ; 

if  infont  (id,  ft)  =  falseO  then 
getfont ( id , f t)  =  undef; 
endif ; 

rctfont(ft)  =  farea(getfont(id,ft)); 

getfont ( id , setfont ( f , id , ft)  )  =  f; 

getfont (id , setfont (a , id , setfont (b , id , ft) )  )  =  a; 

of f set font (x ,y , f t ,p)  =  locpnt ( 

sumint (xcord (p) , ml tint (x, xdimrct (rctfont ( ft) )  ) ) 

sumint (ycord (p) , ml tint (y, ydimrct (rctfont ( ft) )  ) ) 

)  ; 

end  extend; 
end  iconfont; 


spec  pntblktrans 


extend 

natural , 
integer, 
point, 
rectangle , 
m 


/*  initialize  ptblt  */ 
/*  get  source  ret  */ 

/*  get  destination 


primitive 
op 

initptblt:  ^  ptblt; 
getsret:  ptblt  ->■  ret; 
getdret :  ptblt  -*•  ret; 

ret  */ 

getcrct:  ptblt  ->  ret;  /*  get  clipping  ret  */ 

getrule;  ptblt  ^  nat;  /*  get  copy  rule  */ 

setsret:  ret, ptblt  ->■  ptblt;  /*  set  source  ret  */ 

setdret :  ret, ptblt  -»■  ptblt;  /*  set  destination 

ret  */ 

setcrct:  ret, ptblt  -»■  ptblt;  /*  set  clipping  ret  */ 

setrule:  nat, ptblt  ptblt;  /*  set  copy  rule  */ 

^it'k'kie'kitie-kicicit’kit’kie*-k-kicicifk’kic'k'k*ic-k-k'k-k-k*-k-k-kic'kic 

*  copyblt  -  form  copy  operation: 

*  given  source,  mask  destination  forms; 

*  call  cpyrecur  with  origin  of  wksrct 

*  ptblt  controls  operation; 

*/ 

copyblt:  ptblt , form, form, form  ^  form; 

y'*************>r************************** 

*  drawline  -  draws  line  between  two  pnts : 

*  given  start  pnt,  stop  pnt,  brush,  destination 
mask  ; 

*  calls  recursive  h/v  drawloop  depending  on 
slope  of  line 

*  drawloop  constructs  line  using  repeated 

*  calls  to  copyblt  using  source  form  as  a 
brush 

*/ 

drawline:  pnt ,  pnt ,  ptblt ,  form,  form,  form  form; 

y/**************************************** 

*  copyfont  -  copy  icon  from  font  to  a  given 
point  in  the  dest  form 

*  the  source  and  dest  ret  in  ptblt  are 
automatically  set 

V 

copyfont:  pnt ,  ptblt ,  nat ,  font ,  form ,  form  -»■  form; 
^**************************************** 

*  inveopyfont  -  same  as  copyfont  bit  with 
inverse  coloring  on  the 

*  the  font  form  source. 

V 

inveopyfont :  color , color , pnt , ptblt, nat , font , form, 
form  form; 

hidden 

op 

^**************************************** 

*  wksrct  -  working  source  ret 

*  intersection  of  source  form  farea 

*  and  the  ptblt  source  ret 


wksrct;  fonn,ptblt  -»■  ret; 

y'*************************************** 

*  wkdret  -  working  destination  ret 

*  interseetion  of  destination  form  farea 

*  and  the  ptblt  destination  ret 
*/ 

wkdret:  form, ptblt  ^  ret; 

^*************************************** 

*  modpnt  -  pnt  modulo  (2D  modulo).  : 

*  given  pnt  P,  form  F 

*  if  P  in  F 

*  then  P 

*  else (wrap  P  around  into  F) 

*  reduee  eoord  of  P 

*  by  dim  of  F 

*  until  P  in  F 
*/ 

modpnt:  pnt,  form  -<■  pnt; 

y**** *********************************** 

*  getmeolor  -  applies  the  masking  rules 

*  given  pnt  P,  souree  S,  dest  D,  mask  M, 

ptb It  B 

*  returns  eolor  MS  (masked  souree  eolor) 

*  based  on: 

*  masking  poliey 

*  S  eolor  @  P 

*  M  eolor  @  modpnt  of 

*  matehpnt  of  P,S,D,B 
*/ 

getmeolor:  pnt , ptblt ,  form,  form,  form  eolor; 
y**************************************** 

*  nextpnt  -  given  pnt  P,  returns  next  pnt 

in  wksret 

*  based  on  sequential  ordering  imposed  on  ret 

*  start  at  origin 

*  if  right  neighbor  of  P  in  ret 

*  then  return  right  neighbor  of  P 

*  else 

*  move  left  to  ret  boundary 

*  return  pnt  above 
*/ 

nextpnt:  pnt ,  ptblt ,  form  pnt; 

y**************************************** 


*  matehpnt  -  find  eorresponding  pnt  in  dest 

*  given  pnt  P,  souree  S,  dest  D,  ptblt  B 

*  returns  pnt  that  is  offset  XY  from  the 

*  origin  of  the  wkdret 

*  where  XY  is  the  offset  from  the 

*  origin  of  the  wksret 

*  that  equals  P 
*/ 

matehpnt:  pnt ,  ptblt ,  form ,  form  -*•  pnt; 


y***************************************** 

*  copypnt  -  set  color  at  pnt  in  dest 

*  given  pnt  P,  source  S,  dest  D,  mask  M, 

ptblt  B 

*  set  color  @  matchpnt  of  P,S,D,B 

*  based  on: 

*  B  copy  rule 

*  MS  color  from  getmcolor  of  P,S,M 

*  D  color  @  matchpnt  of  P,S,D,B 

V 

copypnt:  pnt ,  ptblt ,  form,  form,  form  -<■  form; 

y/***************************************** 

*  cpyrecur  -  recursive  function  of  copybit 

*  given  pnt  P 

*  if  P  in  wksrct 

*  then 

*  call  copypnt  with  P 

*  call  cpyrecur  with  nextpnt  of  P 

*  else 

*  stop  recursion 

*/ 

cpyrecur:  pnt ,  ptblt ,  form,  form,  form  ->■  form; 

^■k**************************************** 

*  hdrawloop  -  recursive  function  of  drawline 

*  used  when  absolute  value  of  slope  is  <  45 

degrees 

*  walks  line  one  horizontal  point  at  a  time 

*  moving  vertically  as  required, 

*  at  each  step:' 

*  sets  ptblt  destination  ret 

*  calls  copybit 
*/ 

hdrawloop:  nat , int , int , int , int , int , form, 
form, ptblt  ->■  form; 

y'***************************************** 

*  vdrawloop  -  recursive  function  of  drawline 

*  used  when  absolute  value  of  slope  is  >=  45 

degrees 

*  walks  line  one  vertical  point  at  a  time 

*  moving  horizontally  as  required 

*  at  each  step: 

*  sets  ptblt  destination  ret 

*  calls  copybit 

*/ 

vdrawloop :  nat , int , int , int , int , int , form , 
form, ptblt  form; 

Lorn 

getsret ( initptblt ( ) )  =  area ( 

locpnt ( zeroint { ) , zeroint () ) , 
locpnt ( zeroint ( ) , zeroint ( ) ) 


getdrct (initptblt ( ) )  =  area ( 
locpnt ( zeroint ( ) , zeroint ( ) ) , 
locpnt ( zeroint ( ) , zeroint ( ) ) 

)  ; 

getcrct ( initptblt 0 )  =  area{ 
locpnt ( zeroint ( ) , zeroint () ) , 
locpnt ( zeroint ( ) , zeroint ( ) ) 

)  ; 

getrule  (initptblt  0  )  =  zeronat(.); 
getsrct (setsrct (r ,pb) )  =  r; 
getdrct (setdrct (r,pb) )  =  r; 
getcrct (setcrct (r ,pb) )  =  r; 
getrule (setrule(n,pb) )  =  n; 

wksrct(f,pb)  =  intsctrct (farea ( f ) ,getsrct (pb) ) 
wkdrct(f,pb)  =  intsctrct (farea ( f) ,getdrct (pb) ) 
modpnt(p,f)  =  offsetpnt( 

modint (xcord (p) ,xdimrct ( farea ( f) )  ) , 
modint (ycord (p) ,ydimrct ( farea ( f) )  ) , 
origin ( farea ( f) ) 

)  ; 

y**************************************** 

*  matchpnt 

*  p:  pnt  in  source 

*  pb :  ptblt 

*  s:  source 

*  d:  dest 

*****************************************/ 
matchpnt (p,pb,s,d)  =  offsetpnt( 
subint ( 

xcord (p) , 

xcord (origin (wksrct (s ,pb) )  ) 

)  , 

subint ( 

ycord (p) , 

ycord(origin(wksrct(s,pb) )  ) 

)  , 

origin (wkdrct (d,pb) ) 

)  ; 

/**it*i,1fkit***********-k1t****1ticit**it***-k**ir** 

*getmcolor 

*  p;  pnt  in  source 

*  pb :  ptblt 

*  s:  source 

*  m:  mask 

*  d:  destination 

**************************************** y 

if  or  ( 

eqcolor (getcolor (p,s) ,nullcolor() ) , 
eqcolor ( 

getcolor (modpnt (matchpnt (p , pb , s , d) ,m) ,m) 


nullcolor ( ) 


) 

)  =  true { ) 
then 

getmcolor  (p  ,pb  ,  s  ,m,d)  =  getcolor  (,p ,  s)  ; 
else 

getmcolor  (p  ,pb ,  s  ,in,d)  =  getcolor  (modpnt 
(matchpnt  (p,pb  ,s  ,d)  ,in)  ,m)  ; 

endif ; 

^**************************************** 

*  nextpnt 

*  p:  pnt  in  source 

*  pb :  ptblt 

*  s :  source 

*****************************************y 

if  ltint( 
xcord (p) , 

xcord ( corner ( wksrc t ( s ,  pb )  )  ) 

)  =  trueO 
then 

nextpnt (p ,pb , s)  =  locpnt( 
succint (xcord (p) ) , 
ycord (p) 

)  ; 

else 

nextpnt (p,pb,s)  =  locpnt( 

xcord (origin (wksrct (s ,pb) )  ), 
succint (ycord (p) ) 

)  ; 

endif; 

y**************************************** 

*  copypnt 

*  p;  pnt  in  source 

*  pt;  ptblt 

*  s :  source 

*  m:  mask 

*  d:  destination 

***************************************** y 
if  inrct ( 

matchpnt (p ,pb , s ,d) 
intsctrct ( 

wkdrct (d ,pb) , 
getcrct (pb) 

) 

)  =  trueO 
then 

if  getrule(pb)  =  zeronatO 
then 

copypnt (p ,pb , s ,ra,d)  =  d; 
else  if  getrule(pb)  =  11] succnat ( zeronat ( ) ) 


if  and( 

not  (eqcolor  (getmcolor  (p  ,pb ,  s  ,in,d)  , 
nullcolor ( ) )  )  , 
not (eqcolor ( 
getcolor ( 

matchpnt (p,pb , s ,d) , 
d 

)  , 

nullcolor ( ) 

)  ) 

)  =  true ( ) 
then 

copypnt (p,pb,s,m,d)  =  setcolor{ 
matchpnt (p,pb , s ,d) , 
getmcolor (p,pb,s,m,d) , 
d 

)  ; 

else 

copypnt (p ,pb , s ,m,d)  =  d; 
endif ; 

else  if  getrule(pb)  =  [2] succnat ( zeronat ( ) ) 
then 

if  and ( 

not (eqcolor (getmcolor (p,pb , s ,m,d)  , 
nullcolor ( > )  )  , 
eqcolor ( 

getcolor ( 

matchpnt (p,pb , s ,d) , 
d 

)  , 

nullcolor ( ) 

) 

)  =  true ( ) 
then 

copypnt (p,pb,s,m,d)  =  setcolor( 
matchpnt (p,pb , s ,d) , 
getmcolor (p,pb , s ,m,d) , 
d 


else 

copypnt (p,pb,s ,m,d)  =  d; 
endif ; 

else  if  getrule(pb)  =  [3] succnat (zeronat ( ) 
then 

if  getmcolor(p,pb,s,m,d)  !=  nullcolorO 
then 

setcolor ( 

matchpnt (p,pb , s ,d) , 
getmcolor (p,pb,s,m,d) , 


else 

copypnt (p ,pb , s ,m, d)  =  d; 
endif ; 

else  if  getrule(pb)  =  [4] succnat (zeronat 0 ) 
then 

if  and( 

eqcolor (getmcolor (p,pb , s ,m, d) , 

nullcolor ( ) ) , 
not (eqcolor ( 
getcolor ( 

matchpnt (p,pb , s ,d) , 
d 

)  , 

nullcolor ( ) 

)  ) 

)  =  true  0 
then 

copypnt (p ,pb , s ,m,d)  =  setcolor( 
matchpnt (p,pb,s,d) , 
nullcolor ( ) , 
d 

)  ; 

endif ; 

else  if  getrule(pb)  =  [5] succnat (zeronat {) ) 
then 

if  getcolor ( 

matchpnt (p ,pb , s ,d) , 
d 

) )  !=  nullcolor 0 

then 

copypnt (p ,pb , s ,m,d)  =  setcolor( 
matchpnt (p,pb , s ,d) , 
getmcolor (p,pb , s ,m, d) , 
d 

)  ; 

else 

copypnt (p,pb,s,m,d)  =  d; 
endif ; 

else  if  getrule(pb)  =  [ 6] succnat ( zeronat () ) 
then 

if  and( 
or  ( 

eqcolor (getmcolor (p, pb , s ,m,d) , 
nullcolor () ) , 
not (eqcolor ( 
getcolor ( 

matchpnt ( p , pb , s , d ) , 
d 

)  , 


nullcolor  ( ) 


not  (eqcolor  (getmcolor  (.p,pb ,  s  ,m, d) 
nullcolor { ) ) )  ) , 

eqcolor { 

getcolor ( 

matchpnt  (p,pb , s,d)  , 
d 

)  , 

nullcolor { ) 

) 

) 

)  =  trueO 
then 

copypnt  (p,pb  ,s  ,in,d)  =  setcolorC 
matchpnt (.p,pb,s,d)  , 
getmcolor (p,pb , s ,m,d) , 
d 

)  ; 

else 

copypnt (p,pb,s,m,d)  =  d; 
endif ; 

else  if  getrule(pb)  =  [7] succnat ( zeronat () 
then 

if  or( 

not (eqcolor (getmcolor (p,pb ,s ,m,d) , 
nullcolor ( ) )  ) , 
not (eqcolor ( 
getcolor ( 

matchpnt (p,pb,s,d) , 
d 

)  , 

nullcolor ( ) 

)  ) 

)  =  trueO 
then 

copypnt (p,pb ,sm,d)  =  setcolor( 
matchpnt (p,pb,s,d) , 
getmcolor (p,pb , s,m,d) , 
d 

)  ; 

else 

copypnt (p,pb ,s ,m,d)  =  d; 

else 

copypnt (p,pb ,s ,m,d)  =  d; 
endif ; 
endif ; 
endif ; 
endif ; 
endif ; 
endif ; 
endif ; 


*  p:  minor  axis  move  counter  (vertical) 

*  dx:  xDelta  sign 

*  dy :  yDelta  sign 

*  px:  yDelta  abs 

*  py:  xDelta  abs 

*  s :  source  form 

*  d:  dest  form 

*  m:  mask  form 

*  pb :  ptblt 

**************************************** ^ 

/*  is  it  the  last  step?  */ 
if  n  =  succnat ( zeronat ( ) ) 
then 

/*  time  to  move  in  minor  direction?  */ 
if  Itint (subint (p,px) , zeroint ( ) )  =  true ( ) 
then 

/*  move  minor  */ 

hdrawloop (n ,p,dx,dy , px , py , s ,d ,m, pb  = 
copyblt ( 

setdrct (shiftrct (dx , dy , getdrct (pb) ) ,pb) 

s, 

m, 

d, 

)  ; 

else 

/*  move  major  */ 

hdrawloop ( n , p , dx , dy , px , py , s , d ,m , pb )  = 
copyblt ( 

setdrct (shiftrct (dx, zeroint ( ) , 
getdrct (pb) ) ,pb) 
s , 
m, 
d, 

)  ; 

endif ; 

else  if  Itint (subint (p,px) , zeroint 0 )  =  true ( ) 
then 

/*  move  minor  and  continue  */ 
hdrawloop ( n , p , dx , dy , px , py , s , d , m , pb )  = 

hdrawloop ( 

/*  reduce  distance  to  go  */ 
subnet ( n , succnat ( zeronat ( ) ) , 

/*  reset  counter  for  next  minor  move  */ 
sumint (subint (p,px) ,py) , 

dx, 

dy , 
px, 

py» 
s , 

/*  move  minor  and  major  then  copy  brush  */ 


copyblt ( 

setdrct ( shif tret ( dx , dy , ge tdret ( pb ) ) , pb ) 


setdret (shif tret (dx,dy ,getdret (pb) ) ,pb) 

).  ; 
else 

/*  move  major  and  oontinue  */ 
hdrawloop ( n , p , dx , dy , px , py , s , d , m , pb )  = 
hdrawloop ( 

/*  reduee  dist  to  go  */ 
subnat (n , sueenat ( zeronat ( )  )  , 

/*  reduee  eount  till  next  minor  move  */ 
subint (p,px) , 

dx , 

dy , 
px, 

py» 

S, 

/*  move  major  then  oopy  brush  */ 
eopyblt ( 

setdret (shiftret (dx, zeroint ( )  , 
getdret (pb) ) ,pb) 
s, 
m, 
d. 


setdret (shiftret (dx, zeroint ( ) , getdret (pb) ) 
pb) 

)  ; 

endif ; 
endif ; 

^**************************************** 

*  vdrawloop 

*  n;  dist  to  go  (major  axis) 

*  p:  minor  axis  move  eounter  (horizontal) 

*  dx;  xDelta  sign 

*  dy :  yDelta  sign 

*  px:  yDelta  abs 

*  py :  xDelta  abs 

*  s;  souree  form 

*  d:  dest  form 

*  m:  mask  form 

*  pb :  ptblt 

************************<r****************y 

/*  is  it  the  last  step?  */ 
if  n  =  sueenat ( zeronat O ) 


/*  last  step  */ 

if  .Itint  ( siabint  (p,py)  ,  zeroint  ( )  )  =  true() 
then 

/*  move  minor  */ 

vdrawloop (n ,p ,dx,dy ,px, py , s ,d,m, pb)  = 
copyblt ( 

setdrct (shiftrct (dx,dy ,getdrct (pb) ) ,pb) 

s, 

m, 

d, 

)  ; 

else 

/*  move  major  */ 

vdrawloop (n ,p,dx,dy ,pz ,py , s ,d ,m,pb)  = 
copyblt ( 

setdrct (shiftrct ( zeroint 0 ,dy, 
getdrct(pb) ) ,pb) 
s, 
m, 
d, 

)  ; 

endif ; 

else  if  Itint  (si±)int  (p, py)  , aeroint  ( )  )  =  true  ( ) 
then 

/*  move  minor  and  continue  walk  */ 
vdrawloop ( n , p , dx , dy , px , py , s , d , m , pb )  = 

vdrawloop ( 

/*  reduce  dist  to  go  */ 
subnat (n , succnat ( zeronat ( ) )  ), 

/*  set  counter  for  next  minor  move  */ 
sumint ( subint (p , py) ,px) , 

dx , 

dy , 
px, 

py^ 

S, 

/*  move  minor  and  major  then  copy  brush  */ 
copyblt ( 

setdrct (shiftrct (dx,dy ,getdrct (pb) ) ,pb) 

s, 

m, 

d, 

)  , 
m, 

setdrct ( shiftrct (dx, dy ,getdrct (pb) ) ,pb) 

)  ; 
else 

/*  move  major  and  continue  walk  */ 
vdrawloop ( n , p , dx , dy , px , py , s , d , m , pb )  = 

vdrawloop ( 


/*  reduce  dist  to  go  */ 
subnet  (n,succnat(zeronat  (.)  )  ), 

/*  reduce  co\int  till  minor  move  */ 
subint(p,py) , 

dx, 

dy , 
px, 

py» 

s, 

/*  move  major  and  copy  brush  */ 
copyblt ( 

setdrct (shiftrct (zeroint ( ) ,dy, 
getdrct (pb) ) ,pb) 
s, 
m, 
d, 

)  , 

m, 

setdrct ( shiftrct ( zeroint ( ) ,dy , getdrct (pb) ) , 
pb) 

)  ; 

endif ; 
endif; 

/*************★************************** 

*  drawline 

*  pi;  start  pnt 

*  p2:  end  pnt 

*  pb :  ptblk 

*  s:  brush  form 

*  m;  mask  form 

*  d:  dest  form 

***************************************** 
if  and( 

subint (ycord (p2) ,ycord(pl) ) , 
siibint (xcord (p2)  ,xcord(pl)  ) 

)  =  true ( ) 
then 

/*  line  is  a  single  pnt  */ 

drawline (pi , p2 ,pb , s ,m,d)  =  copyblt (pb , s ,m,d) ; 

else  if  ltint( 

absint (subint (ycord (p2 , ycord (pi)  )  )  , 

absint ( subint (xcord (p2) , xcord (pi) )  ) 

)  =  trueO 
then 

/*  line  is  horizontal  */ 
drawline(pl,p2,pb,s,m,d)  = 
hdrawloop ( 

/*  distance  to  go  */ 

iton(absint (subint (xcord(p2) ,xcord(pl) )  ) ) 

/*  dist  till  minor  move  counter  */ 


divint ( 

absint  (siibint(xcord(p2)  ,xcord(pl)  )  )  )  , 

[ 2] succint (zeroint ( )  ) 

)  , 

/*  dx  */ 
divint ( 

subint (xcord (p2) ,xcord(pl) ) , 
absint (subint (xcord (p2) , xcord (pi) )  ) 

)  , 

/*  dy  */ 
divint ( 

subint (ycord(p2) ,ycord(pl) ) , 
absint (subint (ycord (p2) ,ycord(pl) )  ) 

)  , 

/*  px  */ 

absint ( subint (ycord (p2)  ,ycord(pl) )  )  , 

/*  py  */ 

absint (subint (xcord (p2)  ,xcord(pl) )  )  , 

s , 

copyblt (pb , s ,m, d) , 

m, 

pb 

)  ; 

else 

/*  line  is  vertical  */ 
drawline  (pi  ,p2  ,pb,s  ,in,d)  = 
vdrawloop ( 

/*  dist  to  go  */ 

iton (absint (subint (ycord (p2) ,ycord(pl) )  ) ) , 

/*  dist  till  minor  move  counter  */ 
divint ( 

absint (subint (ycord (p2) ,ycord(pl) )  ) , 

[  2 ] succint (zeroint ( )  ) 

)  , 

/*  dx  */ 
divint ( 

subint (xcord (p2) , xcord (pi) ) , 
absint (subint (xcord (p2) , xcord (pi) )  ) 

)  , 

/*  dy  */ 
divint ( 

subint (ycord (p2) , ycord (pi) ) , 
absint(subint (ycord(p2) ,ycord(pl) )  ) 

)  , 

/*  px  */ 

absint (subint (ycord (p2) ,ycord(pl) )  ) , 

/*  py  */ 

absint (subint (xcord (p2) ,xcord(pl) )  ) , 

s, 

copyblt (pb,s,m,d) , 


A  >  iVit 
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^  r* /, 


I! 


m, 

pb 

)  ; 

endif ; 
endif ; 

y**************************************** 

*  copyfont 

*  p:  position  in  destination  for  lower  left 

corner  of  source  form 

*  pb ;  ptblt 

*  id:  index  number 

*  ft:  font  with  source  form 

*  m:  mask 

*  d;  destination  form 

*****************************************  y' 

copyfont (p,pb, id, ft, m,d)  =  copyblt( 
setdrct ( 

putrct (p,rctfont (ft) )  , 
setsrct (rctfont ( ft ) ,pb) 

) 

getfont (id, ft) , 

m, 

d, 

)  ; 

y**************************************** 

*  invcopyfont 

*  cl:  foreground  color 

*  c2:  background  color 

*  p:  position  in  destination  for  lower  left 

corner  of  source  form 

*  pb :  ptblt 

*  id:  index  number 

*  ft:  font  with  source  form 

*  ra:  mask 

*  d:  destination  form 
********'***********************•***★****** 

invcopyfont (cl ,c2 ,p,pb, id, ft ,m,d)  =  copyblt( 
setdrct ( 

putdrct ( p, rctfont ( f t ) ) , 
setsrct ( rctfont ( ft) ,pb) 

) 

invform (cl , c2 ,getfont ( id , ft ) ) , 

m, 

d, 

)  ; 

end  extend; 
end  pntblktrans; 


t 
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spec  identifiers 
is 

extend 

boolean 

with 

sort 

mem id ; 
regid; 
stkid; 
dregid; 
fid; 
qid; 
dbid  ; 
primitive 
op 

idopers (memid,memseg)  ; 
idopers { regid , regseg) ; 
idopers ( stkid , stkseg) ; 
idopers (dregid, dregseg) ; 

idopers (qid, qseg) ; 
axiom 

idaxioms (memid,memseg) ; 
idaxioms (regid, regseg) ; 
idaxioms (stkid, stkseg) ; 
idaxioms (dregid , dregseg) ; 
idaxioms (qid , qseg)  ; 
end  extend; 
end  identifiers; 


/*  queue  ID  */ 

/*  database  ID  */ 


/*  memory  seg  id  */ 

/*  register  seg  id  */ 
/*  stack  seg  id  */ 

/*  display  register 
seg  id  */ 

/*  queue  segment  ID  */ 


spec  memaddress 
is 

extend 

identifiers , 
boolean 
with 

sort 

meroaddr ; 
primitive 
op 

startmemaddr ;  memid  memaddr; 

nextmemaddr:  memaddr  memaddr; 

prevmemaddr:  memaddr  ->•  memaddr; 

getmemid:  memaddr  memid; 

offset:  int, memaddr  -»■  memaddr;  /*  offset  from 

memaddr  */ 

eqmemaddr  :  memaddr ,  memaddr  ->•  bool; 
axiom 

prevmemaddr (startmemaddr ( i) )  =  undef; 

prevmemaddr (nextmemaddr (m) )  =  m; 
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nextmemaddr (prevmemaddr (m) )  =  m; 

offset  (succint(n)  ,m)  =  nextmemaddr  (of  f set  (n  ,in)  )  ; 

if  offset (n,m)  =  startmemaddr ( ) 

then 

of fset (predint (n) ,m)  =  undef; 
else 

of fset (predint (n) ,m)  =  prevmemaddr (of fset (n ,m) ) 
endif; 

eqmemid ( i ,getmemid (offset (n , startmemaddr ( i) )  ))  = 

true ( ) ; 

eqmemaddr  (startmem.addr  (il)  ,  startmemaddr  (i2)  )  = 

eqmemid ( i 1 , i 2 ) ; 

eqmemaddr (startmemaddr (i) , nextmemaddr ( a) )  = 

false ( ) ; 

eqmemaddr ( nextmemaddr ( al )  , nextmemaddr ( a  2 ) )  = 

eqmemaddr (al , a2) ; 
of fset (zeroint ( ) ,m)  =  m; 
equivrel (eqmemaddr ,memaddr) ; 
end  extend; 
end  memaddress ; 


spec  regaddress 
is 

extend 

identifiers , 
boolean 
with 

sort 

regaddr ; 
primitive 
op 

startregaddr :  regid  -*■  regaddr; 
nextregaddr:  regaddr  -►  regaddr; 
prevregaddr;  regaddr  regaddr; 
getregid:  regaddr  regid; 
eqregaddr;  regaddr , regaddr  bool; 

axiom 

prevregaddr (startregaddr ( i) )  =  undef; 
prevregaddr (nextregaddr (m) )  =  m; 
nextregaddr (prevregaddr (m) )  =  m; 
eqregaddr (startregaddr ( il) , startregaddr ( i2) )  = 

eqregid ( il , i2) ; 

eqregaddr (startregaddr (i) , nextregaddr (a)  )  = 

false ( ) ; 

eqregaddr (nextregaddr (al) , nextregaddr (a2) )  = 

eqregaddr (al ,a2) ; 
equivrel (eqregaddr, regaddr)  ; 
end  extend; 
end  regaddress; 


spec  stkaddress 
is 

extend 

identifiers , 

boolean  * 

with 

sort 

stk.addr ; 
primitive 
op 

getstkid:  stkaddr  stkid; 
eqstkaddr:  stkaddr  ,  stkaddr  bool; 
axiom 

eqstkaddr (nextstkaddr (al) ,nextstkaddr (a2) )  = 

eqstkaddr (al ,a2) ; 
equivrel (eqstkaddr , stkaddr)  ; 
end  extend; 
end  stkaddress; 


spec  qaddress  /*  database  part  */ 

is 

extend 

identifiers , 
boolean 
with 

sort 

qaddr ; 
primitive 
op 

getqid:  qaddr  -*■  qid; 
eqqaddr;  qaddr, qaddr  ->•  bool; 
axiom 

eqqaddr (nextqaddr (al) , nextqaddr ( a2 ) )  = 

eqqaddr ( al , a2) ; 
equivrel (eqqaddr , qaddr) ; 
end  extend; 

end  qaddress;  /*  database  part  */ 

spec  dregaddress  /*  display  part  */ 

is 

extend 

identifiers , 
boolean 
with 

sort 

dregaddr ; 
primitive 
op 


startdregaddr ;  dregid  dregaddr; 


nextdregaddr :  dregaddr  dregaddr; 
prevdregaddr :  dregaddr  -*•  dregaddr; 
getdregid;  dregaddr  dregid; 
eqdregaddr:  dregaddr , dregaddr  ->  bool; 
axiom 

prevdregaddr (startdregaddr (i) )  =  undef; 

prevdregaddr (nextdregaddr (m) )  =  m; 

nextdregaddr (prevdregaddr (m) )  =  m; 

eqdregaddr (startdregaddr (il) , startdregaddr (i2) )  = 

eqdregid(il ,i2) ; 

eqdregaddr ( startdregaddr ( i) , nextdregaddr (a) )  = 

false ( ) ; 

eqdregaddr ( nextdregaddr (al) , nextdregaddr ( a2 ) )  = 

eqdregaddr (al ,a2) ; 
equivrel ( eqdregaddr , dregaddr ) ; 
end  extend; 
end  dregaddress; 

spec  monitorattribute 
is 

extend 

boolean 

with 

sort 

mattribute ; 
primitive 
op 

xpixels:  mattribute; 

ypixels:  mattribute; 

hscrnsize;  -►  mattribute; 
vscrnsize:  mattribute; 

intenscapbl:  -*•  mattribute; 
colorcapbl:  ^  mattribute; 
backgnd:  mattribute; 

dselect;  -*■  mattribute; 

eqmattribute;  mattribute , mattribute  bool; 
axiom 

equivrel ( eqmattribute , mattribute) ; 
end  extend; 

end  monitorattribute;  /*  display  part  */ 


spec  files 
is 

extend 

identifiers , 
boolean 


primitive 

op 

getfile:  fid  file; 
eqfile:  file, file  -►  bool; 
axiom 

eqfile(getfile(il)  ,getfile(i2) )  =  eqfid(il,i2); 
equivrel (eqfile, file)  ; 
end  extend; 
end  files; 


spec  operatorclasses 
is 

sort 
mop  ; 
dop; 
top; 
qop; 
sop; 
oop; 
rop  ; 
bop; 

end  operatorclasses; 


spec  instructiontype 
i  s 

sort 

instr ; 

end  instructiontype; 


spec  property_id 
is 

extend 

boolean 

with 

sort 

pid; 

primitive 

op 

pidl;  -►  pid; 
pid2  :  -<■  pid; 


pidn:  -*•  pid; 
eqpid:  pid,  pid  ->■  bool; 
axiom 

equivrel (eqpid , pid)  ; 
end  extend; 
end  property  id; 


/*  database  part  */ 


/*  1st  property_id  */ 
/*  2nd  property_id  */ 


/*  nth  property_id  */ 

/*  equal  property_id  */ 


spec  property_idset 
is 

extend 

boolean , 
prope rty_id 
with 

sort 

pidset ; 
primitive 
op 

0:  pidset; 

u:  ^  pidset; 
crpidset:  pid  -*■  pidset; 


/*  empty  set  */ 
/*  universe  */ 
/*  create  */ 


unpidset;  pidset , pidset  pidset; 

/*  union  */ 

intpidset;  pidset , pidset  pidset; 

/*  intersection  */ 

mempidset:  pid, pidset  -i-  bool;  /*  member  */ 
eqpidset:  pidset ,  pidset  -*•  bool; 

/*  equal  */ 

axiom 

eqpidset (0 ,0)  =  true ( ) ;  /*  empty  pidset  */ 

if  eqpidset {psl , ps2)  =  true { ) 

then 

(eqpidset (unpidset (psl , crpidset (pdl) ) , 

unpidset (ps2,crpidset(pd2) ) )  = 
eqpid(pdl,pd2) ) ; 

endif;  /*  ps :  'pidset'  */ 

/*  pd:  'pid'  */ 

mempidset (pdl , crpidset (pdl) )  =  true ( ) ; 
if  mempidset (pd2 , crpidset (pdl) )  =  true ( ) 
then 

eqpid (pdl ,pd2)  =  true{); 
endif ; 
if  and ( 

eqpidset (psl , ps2) , 
eqpidset (ps2 ,ps3) 

)  =  trueO 
then 

eqpidset  (unpidset  (psl  ,ps2)  ,ps3)  =  trueO; 
eqpidset  (  intpidset  (psl  ,ps2)  ,  ps3)  =  trueO; 
endif ; 
if  and( 

eqpidset (psl ,ps2) , 
eqpidset (ps 2 ,ps 3) 

)  =  trueO 
then 

unpidset (psl ,ps2)  =  unpidset (ps2 ,ps3) ; 
intpidset (psl ,ps2)  =  intpidset (ps2 , ps3) ; 
else  unpidset ( 

unpidset (psl ,ps2) , 


primitive 

op 

vail:  ^  val; 
val2:  -<■  val; 


/*  1st  value  */ 
/*  2nd  value  */ 


vain:  -»•  val;  /*  nth  value  */ 

eqval:  val, val  -►  bool;  /*  equal  value  */ 

axiom 

equivrel (eqval , val) ; 
end  extend; 
end  value; 


spec  valueset 
is 


extend 

boolean , 
value 
with 

sort 

valset ; 
primitive 
op 

0:  -►  valset; 
u:  -►  valset; 
crvalset:  val  valset; 
unvalset:  valset , valset 


/*  empt-'  set  */ 
/*  universe  */ 
/*  create  */ 
valset ; 


/*  union  */ 

intvalset:  valset ,  valset  -*•  valset; 

/*  intersection 

memvalset:  val,  valset  bool;  /*  member  */ 
eqvalset:  valset ,  valset  -*■  bool; 

/*  equal  */ 

axiom 

eqvalset ( 0 , 0 )  =  true  ();  /*  empty  valset 

if  eqvalset ( vsl , vs2)  =  true ( )  /*  vs:  'valset' 

then 

(eqvalset (unvalset (vsl , crvalset (vl) ) , 

unvalset (vs2 , crvalset (v2) ) )  = 
eqval (vl ,v2) ) ;  /*  v:  'val'  */ 

endif; 

memvalset (v , crvalset (v) )  =  true ( ) ; 
if  memvalset  (v2  ,  crvalset  (vl)  )  =  trueO 
then 

eqval(vl,v2)  = 
endif ; 


*/ 


V 

V 


true  ( )  ; 


if  and{ 

eqvalset (vsl , vs3) , 
eqvalset (vs2 ,vs3) 

)  =  true ( ) 
then 

eqvalset  ( unvalset  (vsl ,  vs2 )  ,vs3 )  =  trueO; 
eqvalset (intvalset (vsl ,vs2 ) ,vs3)  =  true ( ) ; 
endif  ; 
if  and ( 

eqvalset (vsl ,vs2) , 
eqvalset ( vs 2 , vs 3) 

)  =  trueO 
then 

unvalset (vsl , vs2 )  =  unvalset(vs2,vs3); 
intvalset(vsl ,vs2)  =  intvalset (vs2 ,vs3) ; 
else  unvalset ( 

unvalset (vsl ,vs2 ) , 
unvalset (vs 2 , vs3) 

)  =  unvalset ( 

unvalset (vsl , vs2 )  , 
vs3 

)  ; 

intvalset ( 

intvalset (vsl ,vs2) , 
intvalset ( vs 2 , vs 3) 

)  =  intvalset ( 

intvalset (vsl ,vs2)  , 
vs3 

)  ; 

endif ; 

memvalset (vl , unvalset (vsl ,vs2) ) 

=  or( 

memvalset (vl , vsl) , 
memvalset (vl , vs2) 

)  ; 

memvalset (vl , intvalset (vsl , vs2) ) 

=  and  ( 

memvalset (vl , vsl ) , 
memvalset (vl , vs 2) 

)  ; 

if  eqvalset (unvalset (vsl ,vs2) , intvalset (vsl , vs2 ) 

=  trueO 

then 

eqvalset (vsl ,vs2)  =  true(); 
endif ; 
if  and( 

and  ( 

not (eqval ( vl , v3) ) , 
not (eqval (v2 , v3) ) 


[ilil 


eqvalset (unvalset (crvalset (vl , 

crvalset(v2) ) ,vs3) 

)  =  trueO 
then 

memvalset  ( v3  ,  vs3)  =  falseO; 
endif; 

associative (unvalset , valset)  ; 
associative (intvalset,valset) ; 
commutative (unvalset, valset) ; 
commutative ( intvalset , valset ) ; 
equivrel ( eqvalset , valset ) ; 
end  extend; 
end  valuset; 


spec  property 
is 

extend 

boolean , 
property_id , 
property_idset , 
value , 
valueset 
with 

sort 

prop; 

primitive 

op 

crprop:  pid, valset  -►  prop;  /*  create  */ 

eqprop:  prop,  prop  -►  bool;  /*  equal  */ 

getid:  prop  ^  pid;  /*  get  property_id  */ 

getvalset:  prop  valset;  /*  get  valueset  */ 

axiom 

if  and( 

eqpid (getid (prl) ,getid(pr2) ) , 
eqvalset (getvalset (prl) , getvalset (pr2) ) 

)  =  trueO 

then  /*  pr:  property  */ 

eqprop (prl , pr2)  =  true();  /*  pd :  property_id  */ 
endif ; 

getid (crprop (pdl ,vsl) )  =  pdl; 
getvalset (crprop (pdl ,vsl) )  =  vsl ; 
equivrel (eqprop, prop) ; 
end  extend; 
end  property; 


spec  propertyset 
is 

extend 

boolean , 
property  id. 


property_idset , 
value , 
valueset , 
property 
h 

sort 

propset ; 
primitive 
op 

0;  -<•  propset;  /*  empty  set  */ 

u:  propset;  /*  universe  */ 

crpropset;  prop  ->  propset;  /*  create  */ 

unpropset:  propset , propset  propset; 

/*  union  */ 

intpropset;  propset , propset  ^  propset; 

/*  intersection  */ 
mempropset:  prop, propset  bool; 

/*  member  */ 

getidset:  propset  -►  pidset;  /*  get  pidset  */ 
eqpropset:  propset , propset  -*■  bool; 

/*  equal  propset  */ 

axiom 

eqpropset ( 0 , 0 )  =  true();  /*  empty  propset  */ 

if  eqpropset (prsl , prs2 )  =  true ( ) 

/*  prs :  'propset'  * 

then 

(eqpropset (unpropset (prsl , crpropset (prl) ) , 

unpropset (prs2 , crpropset (pr2 )  )  )  = 
eqprop(prl,pr2)  )  ; 

endif;  /*  pr :  'prop'  */ 

mempropset ( pr , crpropset (pr) )  =  true ( ) ; 
if  mempropset (pr2 , crpropset (prl) )  =  true  ( ) 
then 

eqprop ( prl , pr2)  =  true ( ) ; 
endif ; 
if  and( 

eqpropset ( prsl , prs3 ) , 
eqpropset (prs 2 ,prs3) 

)  =  trueO 
then 

eqpropset (unpropset (prsl , prs2)  , prs3)  =  true(); 
eqpropset ( intpropset (prsl , prs2 ), prs 3 )  =  true ( ) ; 
endif ; 
if  and( 

eqpropset (prsl ,prs2) , 
eqpropset (prs 2 ,prs3) 

)  =  true ( ) 
then 

unpropset (prsl ,prs2)  =  unpropset (prs2 ,prs3) ; 
intpropset (prsl ,prs2)  =  intpropset (prs2 , prs3) ; 


else  unpropset( 

unpropset (prsl , prs2)  , 
unpropset (prs2,prs3) 

)  =  unpropset ( 

unpropset (prsl , prs2 )  , 
prs3 

)  ; 

intpropset ( 

intpropset (prsl ,prs2) , 
intpropset (prs2 ,prs3) 

)  =  intpropset ( 

intpropset (prsl , prs2) , 
prs3 

)  ; 

end if ; 

mempropset ( pr , unpropset (prsl , prs2 ) ) 

=  or  ( 

mempropset (pr , prsl ) , 
mempropset (pr , prs2) 

)  ; 

mempropset (pr , intpropset (prsl ,prs2) ) 

=  and  ( 

mempropset (pr, prsl) , 
mempropset (pr,prs 2) 

)  ; 

if  eqpropset (unpropset (prsl , prs2 ) , 

intpropset (prsl ,prs2) )  =  true ( ) 

then 

eqpropset  (prsl  ,prs2)  =  trueO; 
endif ; 
if  and ( 
and  ( 

not (eqprop(prl ,pr3) ) , 
not (eqprop (pr2 ,pr3) ) 

)  , 

eqpropset ( unpropset ( crpropset ( pr 1 ) , 

.  _  ,,  crpropset  (pr2)  )  ,prs3)  )  =  true  ( 

theA 

mempropset  (pr3  ,  prs3)  =  falseO; 
endif ; 

if  mempropset ( crprop ( pd , vs ), prs )  =  true ( ) 

/*  pd :  'pid'  * 

then  /*  vs;  'valset 

mempidset ( pd , getidset ( prs) )  =  true ( ) ; 
endif ; 

associative ( unpropset , propset) ; 
associative  ( intpropset , propset) ; 
commute tive ( unpropset , propset ) ; 
commutative ( intpropset , propset) ; 
equivrel ( eqpropset , propset)  ; 
end  extend; 
crocertvset ; 


/*pr : property*/ 


spec  propertyvalue 
is 

extend 

boolean , 
property_id, 
property_idset , 
value, 
valueset , 
property 
with 

sort 

pval  ; 
primitive 
op 

crpval:  pid,val  -*■  pval;  /*  create  */ 

getpid:  pval  ^  pid;  /*  get  property_id  */ 

getval;  pval  -*•  val;  /*  get 

propertyvalue  */ 

eqpval;  pval,  pval  -►  bool; 
memprop:  pval, prop  bool; 

axiom 

getpid{crpval (pd,va) )  =  pd;  /*  pd:  property_id  */ 

getval (crpval (pd ,va) )  =  va;  /*  va;  value  */ 

if  and( 

eqpid{getpid (pv) ,getid(pr)  )  , 
memvalset (getval (pv) ,getvalset (pr ) ) 

)  =  true()  /*  pv: 

propertyvalue  */ 

then 

memprop(pv,pr)  =  trueO; 
endif ; 
if  and ( 

memprop (pvl,pr)  , 
memprop ( pv2 , pr ) 

)  =  trueO 
then 

eqpid  (getpid  (pvl)  , getpid  (pv2)  )  =  trueO; 
endif ; 

if  eqpval (crpval (pdl , val) , crpval (pd2 , va2) ) 

=  true() 

then  and( 

eqpid(pdl,pd2)  , 
eqval (val , va2) 

)  =  true ( ) ; 
endif ; 

equivrel (eqpval , pval) ; 
end  extend; 
end  propertyvalue; 


spec  propertyvalueset 
is 

extend 

boolean , 
property_id , 
property_idset , 
value , 
valueset , 
property , 
property value 
with 

sort 

pvalset ; 
primitive 
op 

0:  ^  pvalset;  /*  empty  set  */ 

u:  pvalset;  /*  universe  */ 

crpvalset:  oval  ^  pvalset;  /*  create  */ 

unpvalset;  pvalset , pvalset  ^  pvalset; 

/*  union  */ 

intpvalset:  pvalset , pvalset  •>  pvalset; 

/*  intersection  */ 
mempvalset:  pval, pvalset  -*•  bool; 

/*  member  */ 

mempset:  pvalset ,propset  -»•  bool; 

/*  member  propset  */ 

getpidset:  pvalset  -*•  pidset;  /*  get  pidset  */ 
eqpvalset:  pvalset , pvalset  bool; 

/*  equal  */ 

axiom 

eqpvalset  ( 0 , 0 )  =  trueO;  /*  empty  pvalset  */ 

if  eqpvalset (pvsl ,pvs2)  =  true() 

/*  pvs :  'pvalset'  */ 

then 

(eqpvalset (unpvalset (pvsl , crpvalset 

(crpval (pdl , vl) ) ) , 
unpvalset (pvs2 , crpvalset 

(crpval (pd2 ,v2) )) )  = 
eqpval (crpval (pdl , vl) , crpval (pd2 , v2) ) ) ; 
endif;  /*  pd:  'pid'  */ 

/*  v:  'val'  */ 

mempvalset  ( pv , crpvalset  (pv) )  =  trueO; 

/*  pv;  'pval'  */ 

if  mempvalset (pv2 , crpvalset (pvl) )  -  true ( ) 
then 

eqpval  (pvl  ,pv2)  =  trueO; 
endif ; 
if  and( 

eqpvalset (pvsl ,pvs3) , 
eqpvalset (pvs2 ,pvs3 ) 

)  =  trueO 


eqpvalset(unpvalset (pvsl ,pvs2) ,pvs3)  =  true{); 
eqpvalset  (intpvalset  (pvs,l,pvs2)  ,pvs3)  =  trueO 
endif ; 
if  and( 

eqpvalset (pvsl ,pvs2) , 
eqpvalset (pvs2 ,pvs3) 

)  =  true() 
then 

unpvalset (pvsl ,pvs2)  =  unpvalset (pvs2 ,pvs3) ; 
intpvalset (pvsl ,pvs2)  =  intpvalset (pvs2 ,pvs3) ; 
else  unpvalset ( 

unpvalset (pvsl, pvs 2)  , 
unpvalset (pvs2 ,pvs3) 

)  =  unpvalset ( 

unpvalset (pvsl , pvs2)  , 
pvs  3 

)  ; 

intpvalset ( 

intpvalset (pvsl ,pvs2) , 
intpvalset (pvs 2 , pvs  3 ) 

)  =  intpvalset ( 

intpvalset (pvsl ,pvs2) , 
pvs  3 


endif  ; 

mempvalset (pv, unpvalset (pvsl, pvs 2) ) 

=  or  ( 

mempvalset (pv, pvsl) , 
mempvalset (pv,pvs2) 

)  ; 

mempvalset (pv, intpvalset (pvsl ,pvs2 ) ) 

=  and  ( 

mempvalset (pv, pvsl) 
mempvalset (pv, pvs 2) 

)  ; 

if  eqpvalset (unpvalset (pvsl ,pvs2) , 

,  ^  ,,  intpvalset  (pvsl  ,pvs2)  )  =  trueO 

theil  =  trueO 

eqpvalset (pvsl ,pvs2)  =  true ( ) 
endi  f  ; 
if  and( 
and  ( 

not (eqpval (pvl ,pv3)  )  , 
not (eqpval (pv2 ,pv3)  ) 

)  , 

eqpvalset (unpvalset (crpvalset (pvl) , 

crpvalset(pv2)  )  ,pvs3)  )  =  trueO 

then 

mempvalset  (pv3 ,pvs3)  =  falseO; 
endif  ; 

if  mempvalset  (crpval  (pd,v)  , pvs)  =  trueO  - 
then 

mempidset  (pd,getpidset  (pvs)  )  =  trueO; 


if  eqpldset (getpidset (pvs) , getidset (prs ) )  =  true ( ) 
then  /*  prs:  'propset'  */ 

mempset (pvs , prs)  =  true(); 
endif ; 

associative ( unpvalset ,pvalset) ; 
associative (intpvalset,pvalset)  ; 
cuiTunutative  (unpvalset  ,pvalset)  ; 
conunutative  ( intpvalset  ,pvalset)  ; 
equivrel (eqpvalset ,pvalset)  ; 
end  extend; 
end  propertyvalueset ; 


spec  object 
is 

extend 

boolean 
property_id 
property_idset , 
value , 

propertyvalue , 
propertyvalueset 
with 

sort 

Ob  j  ; 

primitive 

op 

crob  j  :  pvalset  -*■  ob  j  ;  /*  create  */ 

getopvalset;  obj  -»■  pvalset;  /*  get 

propertyvalueset  */ 
getopidset;  obj  -*■  pidset;  /*get 

property_idset  */ 

getoval:  obj,pid  ^  val;  /*  get  value  */ 

haspval;  pval,obj  -*■  bool;  /*  has 

propertyvalue  */ 

eqobj  :  obj  , obj  ->■  bool;  /*  equal  */ 

axiom 

getopvalset (crob j (pvs) )  =  pvs;  /*  pvs:  'pvalset'  */ 
if  mempvalset (pv,pvs)  =  true ( ) 

/*  /pv:  'pval'  */ 

then 

haspval (pv, crob j (pvs) )  =  true ( ) ; 
endif ; 

getopidset (crob j (pvs) )  =  getpidset (pvs) ; 
if  and ( 

(crpval (pd , v)  =  pv) ,  /*  pd;  'pid'  */ 

mempvalset (pv, pvs)  /*  v:  'val'  */ 

)  =  trueO 
then 

getoval (crob j (pvs) ,pd)  =  v; 
endif ; 


true  ( )  ; 


if  eqpvalset  (pvsl  ,pvs2)  =  trueO 
then 

eqobj (crob j (pvsl) ,crob j (pvs2) )  = 
endif  ; 

eqobj (ol,o2)  =  /*  o:  'obj  '  */ 

eqpvalset (getopvalset (ol) , getopvalset (o2 ) ) ; 
equivrel (eqobj , Ob j ) ; 
end  extend; 
end  object; 


spec  objectclass 
is 

extend 

boolean , 
property_id , 
property_idset , 
obj  ect 
with 

sort 


class ; 
primitive 
op 

0;  -►  class; 
u:  -►  class; 
crclass:  obj  class; 
unclass:  class, class  -►  class; 
intclass:  class, class  -*•  class 
subclass:  class, class  bool; 
memclass:  obj, class  bool; 
getcpidset;  class  pidset; 

insob  j  :  class, obj  -»•  class; 
delobj :  obj, class  ^  class; 
eqclass:  class, class  -*■  bool; 
axiom 

eqclass (0,0)  =  true ( ) ; 
if  eqclass (cl , c2 )  =  true ( ) 
then 

eqclass (unclass (cl, crclass 
unclass (c2 , crclass 
eqpvalset (pvsl ,pvs2) ; 
endif ; 
if  and( 

eqobj (ol ,o2) , 
eqclass (cl ,c2) 

)  =  true ( ) 


/*  empty  class  */ 

/*  universe  */ 

/*  create  */ 

/*  union  */ 

;  /*  intersection  */ 

/*  sidDclass  */ 

/*  member  */ 

/*  get  pidset 
of  class  */ 

/*  insert  */ 

/*  delete  */ 

/*  equal  */ 

/*  empty  class  */ 

/*  c:  'class'  */ 

(crob j (pvsl) ) ) , 

(crob j (pvs2) )  )  )  = 

/*  pvs :  'pvalset'  */ 


/*  o :  'obj  '  */ 


then 

eqclass  (insob  j  (ol , cl)  ,  insobj  (o2  ,c2)  )  =  trueO; 
endif ; 


memclass (o , crclass (o) )  =  true ( ) ; 
if  memclass {o2 , crclass (ol) )  =  true ( ) 
then. 

eqobj(ol,o2)  =  trueO; 
endif ; 
if  and  ( 

eqclass (cl ,c3)  , 
eqclass (c2 , c3) 

)  =  trueO 
then 

eqclass (unclass (cl , c2)  ,  c3)  =  true(); 
eqclass  ( intclass  (cl  ,c2)  ,c3)  =  trueO; 
endif ; 
if  and ( 

eqclass (cl ,c2)  , 
eqclass (c2 , c3) 

)  =  trueO 
then 

unclass (cl , c2)  =  unclass(c2,c3); 
intclass ( cl , c2 )  =  intclass (c2 ,c3) ; 
else  unclass ( 

unclass (cl , c2) , 
unclass (c2 ,c3) 

)  =  unclass  ( 

unclass (cl,c2) , 
c3 

)  ; 

intclass ( 

intclass (cl , c2)  , 
intclass (c2 , c3) 

)  =  intclass ( 

intclass (cl ,c2) 
c3 

)  ; 

endif ; 

memclass (o , unclass (cl ,c2)  ) 

=  or  ( 

memclass (o , cl)  , 
memclass (o , c2) 

)  ; 

memclass (o , intclass (cl , c2)  ) 

=  and  ( 

memclass (o , cl) , 
memclass (o , c2) 


i.  .4 


*  *  1 


if  and( 

and( 

not ( eqob j (ol ,o2) ) , 
not (eqob j (o2 ,o3) ) 

)  , 

eqclass (unclass (crclass (ol) , crclass (o2) )  ,c3) 
)  =  trueO 


V 

d 


memclass  (o3  , c3)  =  falseO; 
endif; 
if  and  ( 

memclass (ol , c)  , 
memclass (o2 ,  c) 

)  =  trueO 
then 

eqpidset (getopidset (ol) , getopidset (o2 ) )  =  true ( ) 
endif; 

if  eqclass (unclass (cl ,c2) , cl)  =  true ( ) 
then 

subclass (c2 , unclass (cl, c2) )  =  true ( ) ; 
else  if  eqclass (unclass (cl ,c2)  , c2 )  =  true ( ) 
then 

subclass (cl , unclass (cl ,c2)  )  =  true ( )  ; 

else  and ( 

subclass (cl , unclass (cl , c2)  )  , 
subclass (c2 , unclass (cl , c2 ) ) 

)  =  true ( ) ; 
endif; 

delob j (o , insob j (c ,o) )  =  c; 

getopidset ( crclass (o) )  =  getopidset (o) ; 

if  not (memclass (ol ,c) )  =  true ( ) 

then 

delobj (ol,c)  =  undef; 

else  delobj (ol , unclass (crclass (ol ) ,crclass(o2) ) ) 

=  crclass (o2 ) ; 

endif ; 

if  not  (eqpidset (getopidset (ol ), getopidset (c) ) ) 

=  trueO 

then 

insobj(c,ol)  =  undef; 

else  insobj (crclass (o2) ,ol)  =  unclass (crclass (o2) , 

crclass (ol) ) ; 

endif ; 

if  eqclass ( intclass (cl , c2) , cl)  =  true() 
then 

subclass  (cl ,  c2)  =  trueO; 
endif; 

associative ( unclass , class) ; 
associative ( intclass , class) ; 
commutative ( unclass , class) ; 
commutative ( intclass , class ) ; 
equivrel (eqclass , class)  ; 
end  extend; 
end  objectclass; 


spec  database 
is 

extend 

property_id , 
property_idset , 
value, 
valueset , 
property , 
propertyset , 
propertyvalue , 
propertyvalueset , 
object , 
ob jectclass , 
identifiers 
with 

sort 
db ; 

primitive 

op 

crdb:  dbid, class  ^  db ;  /*  create  */ 

insclass:  db, class  ^  db ;  /*  insert  new  class  */ 

delclass:  class, db  ^  db ;  /*  delete  class  */ 

retclass:  db, class  pvalset;  /*  retrieve  pvalset 

of  class  */ 

retobj :  db,pval  -  ob j ;  /*  retrieve  obj  by 

pval  */ 

getdbpidset:  db  -<■  pidset;  /*  get  pidset  */ 

modobj  :  db, obj, pval  -*•  db;  /*  modify  obj  */ 

getdb :  dbid  -*•  db ;  •  /*  get  db  by  ID  */ 

getdbid:  db  -»■  dbid;  /*  get  ID  of  db  */ 

memdb :  class,  db  -*■  bool;  /*  member  */ 

eqdb :  db,db  bool;  /*  equal  db  */ 

eqdbid:  dbid, dbid  bool;  /*  equal  ID  */ 

axiom 

if  eqdb(dl,d2)  =  trueO  /*  d:  'db'  */ 

then 

eqdb (insclass(dl,cl) ,insclass(d2,c2))  = 
eqclass (cl  ,c2)  ; 
endif; 

memdb  (c  ,  crdb  { i  ,  c)  )  =  trueO;  /*  c:  'class'  */ 
memdb (c , insclass (d,c) )  =  true(); 

/*  i:  ID  */ 

delclass (c , insclass (d,c) )  =  d; 
if  and( 

and  ( 

eqpvalset(getopvalset (o) ,pvs) , 

/*  o :  'obj  '  */ 

memclass (o , c)  /*  pvs:  'pvalset'  */ 

)  r 

memdb ( c , d ) 

)  =  trueO 


then 

intpvalset ( retclass (d ,c) , pvs)  =  pvs ; 
endif ; 
if  and( 

and  ( 

haspval (pv,o) ,  /*  pv:  'pval'  */ 

memclass (o , c) 

)  , 

memdb ( c , d ) 

)  =  trueO 
then 

retobj (d,pv)  =  o; 
endif ; 

if  not  (memdb  (cl ,  d)  )  =  trueO 
then 

delclass (cl ,d)  =  undef; 
else  delclass (cl , crdb ( i , unclass (cl , c2) ) )  = 

crdb ( i , c2)  ; 

endif ; 

if  memdb  (cl,d)  =  trueO 
then 

insclass (d , cl)  =  undef; 
else  if  and( 

and  ( 

not (memdb (cl , d) ) , 
memdb (c2 ,d) 

)  , 

not (eqpidset (getcpidset ( cl) , 
getcpidset (c2) ) ) 

)  =  trueO 
then  and( 

eqclass (insclass (crdb ( i ,c2) ,cl) , 

crdb ( i , unclass (cl , c2) ) ) , 
eqpidset (getdbpidset (d) , unpidset 

(getcpidset (cl) , getcpidset (c2) ) ) 

)  =  trueO  ; 
endif ; 
if  and( 

and  ( 

memclass (o , c) , 
haspval (pv,o) 

)  , 

memdb  (c  ,d) 

)  =  true ( ) 
then 

mempvalset (pv, retclass (d,c) )  =  true ( ) ; 
endif ; 


if  and ( 

and  ( 
and  ( 

and(  /*  pv:  'pval'  */ 

memprop { pv , crprop ( pd , vs ) ) , 

/*  pd:  'pid'  */ 
mempidset (pd ,getidset (prs) ) 

/*  vs:  'valset'  */ 
),  /*  prs:  'propset'  ^ 

eqpidset (getopidset (o) ,getidset (prs) ) 
) ,  /*  o :  ' obj  '  */ 

memclass (o ,c)  /*  d:  ' db '  */ 

)  , 

memdb  (c ,  d) 

)  =  trueO 
then  and ( 

haspval (pv,o) , 

memdb (crclass (o) ,modob j (d ,o , pv) ) 

)  =  true ( ) ; 

else  modob j (d ,o ,pv)  =  undef; 
end if ; 

getdbid (crdb ( i , c) )  =  i ; 

if  eqdb (getdb (il) ,getdb (i2) )  =  true { ) 

then 

eqdbid  ( il ,  i2)  =  trueO; 
endif ; 

equivrel (eqdb  ,db)  ; 
equivrel (eqdbid ,dbid) ; 
end  extend; 
end  database; 


spec  list 
parm 

extend 

boolean , 
string 
with 

sort 

elm; 

primitive 
op 

eqelm:  elm, elm  bool;  /*  equal  */ 

axiom 

equivrel (eqelm, elm) ; 
end  extend; 

extend 

natural , 
boolean 


IS 


1st  ; 
primitive 
op 


nullst:  1st; 

/* 

empty  list  */ 

makelst:  elm  1st; 

/* 

make  list  from 

makenewlst:  1st  1st; 

/* 

elm  */ 

make  list  from 

firstelm:  1st  elm; 

/* 

list  */ 
first  elm  of 

firstlst:  1st  ->■  1st; 

/* 

list  */ 
first  1st  of 

restlst:  1st  1st; 

/* 

list  */ 

rest  of  list  */ 

catlst:  1st, 1st  1st; 

/* 

concatenate  two 

catelm:  elm, 1st  -►  1st; 

/* 

1st  */ 

concatenate  elm 

memelm:  elm,  1st  bool  ; 

/* 

to  1st  */ 
elm  member  of 

memblst:  1st,  1st  -<•  bool; 

/* 

1st  */ 

1st  member  of 

lenlst:  1st  -►  nat; 

/* 

1st  */ 

length  of  1st  *, 

unlst:  1st, 1st  ist; 

intlst:  l^,lst  -  1st; 

/* 

union  */ 

/* 

intersection  */ 

insist:  1st, 1st  -►  1st; 

/* 

insert  */ 

deist:  1st, 1st  -  1st; 

/* 

delete  */ 

getlst:  1st, 1st  -  1st; 

/* 

get  list  */ 

sofirstlst:  1st  1st; 

/* 

set  of  first 

retobjlst:  1st, 1st  ^  1st; 

/* 

lists  */ 
retrieve  objlst 

modlst:  1st, 1st  --  1st; 

/* 

modify  */ 

eqlst:  1st, 1st  -  bool; 

/* 

equal  */ 

axiom 

f irstelm(makelst (k) )  =  k; 
firstelm (catlst (makelst (k)  ,1) ) 

=  k; 

f irstelm(nullst ( ) )  =  undef; 
firstelm (makenewlst (makelst (k) 

)  )  = 

^  k; 

restlst ( catlst (makelst (k)  ,1)  ) 

=  1; 

restlst (nullst ( ) )  =  undef; 
restlst  (makelst  (k)  )  =  nullstO; 


restlst ( catlst (11 , 12) )  =  12; 
f irs tls t (catlst ( 11 , 12) )  =  11; 
if  makelst(k)  =1 
then 

firstlst (makelst (k) )  =  1; 
endif ; 

lenlst  (nullst  ()  )  =  zeronatO; 

lenlst (makelst (k) )  =  succnat ( zeronat ( ) ) ; 


lenlst (restlst ( 1) )  =  subnat ( lenlst ( 1 ) , 

succnat ( zeronat ())); 

lenlst ( catlst ( 11 , 12) )  =  sumnat (lenlst ( 1 1 ), lenlst ( 12 ) ) 
if  and{ 

(1  !=  nullst ( ) )  , 

(restlst(l)  =  nullst()) 

)  =  trueO 
then 

lenlst (1)  =  succnat(zeronat()); 
endif; 

catlst (catlst ( 11 , 12) , 13)  =  catlst(ll,catlst(12,13)); 
catlst (nullst (), 1)  =  catlst ( 1 , nullst () )  =  1 ; 
implies (eqelm(kl ,k2) ,eqlst (makelst (kl) , 

makelst (k2 ) ) )  =  true ( ) ; 

gtnat ( lenlst (makelst (k) ), lenlst ( nullst () )  =  true ( ) ; 

if  (lenlst(ll)  1=  zeronatO) 

then 

gtnat ( lenlst (catlst ( 11 , 12) , lenlst ( 12 )) )  =  true ( ) ; 
else  eqnat (lenlst(catlst(ll,12) , lenlst ( 12 ) ) ) 

=  true  ( )  ; 

endif ; 
if  and( 

( 11  =  nullst  ( )  )  , 

(12  =  nullst 0 ) 

)  =  trueO 
then 

eqlst(ll,12)  =  trueO; 
else  if  ( f irstelm ( 11 )  !=  f irstelm ( 12) ) 

then 

eqlst(ll,12)  =  falseO; 
else  eqlst ( restlst ( 11) ,restlst(12)  )  ; 
endif ; 

if  ( 1  =  nullst ( ) ) 
then 

catelm(k,l)  =  makelst(k); 
else  if  (makelst(k)  =  nullst()) 
then 

catelm(k,l)  =  1; 
else  firstelm(l)  =  k; 
endif ; 

if  ( 11  =  nullst ( )  ) 
then 

unlst(ll,12)  =  12; 

else  if  memelm ( f irstelm( 11) , 12)  =  true ( ) 
then 

unlst ( restlst ( 11 ), 12)  ; 

else  catelm( f irstelm( 11)  , unlst ( restlst ( 11 )  ,12) )  ; 
endi f ; 

memelm(  firstelm(  1)  ,  1)  =  trueO; 
memelm(k , makelst (k) )  =  true(); 
eqlst ( 1 ,makenewlst (restlst(l)))  = 
equivrel (eqlst ,  1st )  ; 


false ( ) ; 


if  eqlst (f irstlst (11 ) , nullst { ) )  =  true() 

/*  recursion  for 
memblst.  */ 

then 

memblst ( 11 , 12)  =  true ( ) ; 
else  if  and( 

not (eqlst ( f irstlst ( 11 ), nullst {) )  =  true ( )  ) 
(eqlst  (firstlst(12)  , nullst  ()  )  =  trueO) 

)  =  trueO 

then 

memblst  ( 11 , 12)  =  falseO; 
else  if  eqlst ( f irstlst (11) , f irstlst ( 12) )  =  true ( ) 
then 

memblst ( restlst ( 11) ,restlst(12) ) ; 
else  memblst ( f irstlst (11) ,restlst(12) ) ; 
endif ; 

if  or(  /*  recursion  for 

intlst  */ 

(eqlst ( 11 , nullst () )  =  true ( ) ) , 

( eqlst  ( 12  ,  nullst  ()  )  =  trueO) 

)  =  trueO 
then 

intlst ( f irstlst ( 11 ), 12)  =  nullst(); 
else  if  memblst (firstlst (11) , 12)  =  true() 
then 

catlst ( firstlst(ll)  , intlst ( restlst ( 11)  ,12)  )  ; 
else  intlst ( restlst ( 11) , 12) ; 
endif ; 

if  or (  /*  recursion  for 

getlst  */ 

(eqlst  ( 11 ,  nullst  0  )  =  trueO), 

(eqlst  ( 12  ,  nullst  0  )  =  trueO) 

)  =  true() 
then 

getlst ( 11 , 12)  =  undef; 
else  if  eqlst ( firstlst ( 11 ), 12)  =  true ( ) 
then 

getlst ( 11 , 12)  =  firstlst ( (restlst ( 11 ))  ? 
else  if  eqlst ( firstlst ( restlst ( 11 )), 12 )  =  true ( ) 
then 

getlst ( 11 , 12 )  =  f irstlst ( 11 )  ; 
else  getlst ( restlst (restlst ( 11) ) ,12) ; 
endif; 

if  or (  /*  recursion  for 

deist  */ 

(eqlst  { 12  ,  nullst  ()  )  =  trueO), 

(not (memblst ( 11 , 12) )  =  true()) 

)  =  trueO 
then 

delst(ll,12)  =  undef; 

else  if  not (eqlst (11 , firstlst (12) ) )  =  true ( ) 


makenewlst (catlst(firstlst(12) , deist (11, 

restlst ( 12) ) ) ) ; 
else  makenewlst (restlst (12) ) ; 
endif ; 

if  /*  recursion  for 

sofirstlst  */ 

1 tnat ( lenlst ( 1) , succnat ( succnat ( zeronat ( ) ) ) ) 

=  trueO 

then 

sofirstlst ( 1)  =  undef; 

else  if  eqnat ( lenlst ( 1) , succnat ( succnat ( zeronat ())) ) 

=  trueO 

then 

sofirstlst ( 1)  =  firstlst(l); 
else  catlst ( f irstlst ( 1) , sofirstlst (restlst 

(restlst (1) ) ) ; 

endif ; 

if  /*  recursion  for 

retobjlst  */ 

eqlst  (  f  irstlst  ( 11)  ,nullst  0  )  =  trueO 
then 

retob j 1st  ( 11 , 12)  =  nullst(); 
else  if  intlst ( 12 , f irstlst ( 11 ) )  =  12 
then 

catlst ( f irstlst (11) , retob j 1st ( restlst ( 11 ) ,12) ) ; 
else  retob j 1st (restlst ( 11) , 12) ; 
endif ; 
if  and ( 

and  ( 
and  ( 
and  ( 

memblst ( 11 , makenewlst ( uni st (12,13) ) ) , 
memblst (12, sofirstlst (14) ) 

)  , 

( sofirstlst ( 15 )  =  sofirstlst ( 14 ) ) 

)  , 

memblst (15,16) 


memblst (16 ,17) 

)  =  true() 
then 

memblst (makenewlst (15) ,modlst (17,15,11) ) 

=  true ( ) ; 

else  modlst ( 17 , 15 , 11)  =  undef; 
endif ; 
end  extend; 


spec  pidlist 
is 

use 

list (property_id) 
where 

pid  is  elm; 
eqpid  is  eqelm; 
end  pidlist; 

spec  pidsetlist 
is 

use 

list (property_idset) 
where 

pidset  is  elm; 
eqpidset  is  eqelm; 
end  pidsetlist; 


spec  vallist 
is 

use 

list (valued 
where 

val  is  elm; 
eqval  is  eqelm; 
end  vallist; 


spec  valsetlist 
is 

use 

list ( valueset) 
where 

valset  is  elm; 
eqvalset  is  eqelm; 
end  valsetlist; 


spec  proplist 
is 

use 

list (property) 
where 

prop  is  elm; 
eqpropis  eqelm; 
end  proplist  ; 
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spec  propsetlist 
is 

use 

list (propertyset) 
where 

propset  is  elm; 
eqpropset  is  eqelm; 
end  propsetlist; 


spec  pvallist 
is 

use 

list (propertyvalue) 
where 

pval  is  elm; 
eqpval  is  eqelm; 
end  pvallist; 


spec  pvalsetlist 
is 

use 

list (propertyvalueset) 
where 

pvalset  is  elm; 
eqpvalset  is  eqelm; 
end  pvalsetlist; 

spec  objlist 
is 

use 

list (object) 
where 

obj  is  elm; 
eqobj  is  eqelm; 
end  objlist; 

spec  classlist 
is 

use 

list (object class) 
where 

class  is  elm; 
eqclass  is  eqelm; 
end  classlist; 


spec  dblist 
is 

use 

list (database) 
where 

db  is  elm; 
eqdb  is  eqelm; 

end  dblist;  /*  database  part  */ 


spec  typing 
is 

extend 

boolean , 
natural , 
integer , 
character , 
str . chartype , 
intensity , 
pointcolor , 
point , 
rectangle , 
imageform, 
pntblktrans , 
iconfont , 
identifiers , 
memaddress , 
regaddress , 
stkaddress , 
dregaddress , 
monitorattribute , 
files , 

operatorclasses , 
instructiontype , 

pidlist,  /*  database  part  */ 

pidsetlist , 
vallist , 
valsetlist , 
proplist , 
propsetlist , 
pvallist , 
pvalsetlist , 
ob j list , 
classlist 
dblist 


/*  database  part  */ 


primitive 

op 

typingopers (bool) ; 
typingopers (nat ) ; 
typingopers (int)  ; 
typingopers (char) ; 
typingopers ( str . char) ; 
typingopers (in tens) ; 
typingopers (color) ; 
typingopers (pnt) ; 
typingopers (ret)  ; 
typingopers ( form) ; 
typingopers (ptblt) ; 
typingopers ( font) ; 
typingopers (memid) ; 
typingopers (regid) ; 
typingopers ( stkid) ; 
typingopers (dregid) ; 
typingopers (fid)  ; 
typingopers (memaddr) ; 
typingopers (regaddr) ; 
typingopers (stkaddr) ; 
typingopers (dregaddr) ; 
typingopers (mattribute) ; 
typingopers (file)  ; 
typingopers (mop) ; 
typingopers (dop) ; 
typingopers (top) ; 
typingopers (qop) ; 
typingopers ( sop) ; 
typingopers (oop)  ; 
typingopers (rop)  ; 
typingopers (bop) ; 
typingopers (instr) ; 

typingopers (pidlist. 1st) ;  /*  database  part  */ 

typingopers (pidsetlist . 1st) ; 

typingopers (vallist. 1st) ; 

typingopers (valsetlist. 1st)  ; 

typingopers (proplist . 1st)  ; 

typingopers (propsetlist . 1st)  ; 

typingopers (pvallist. 1st)  ; 

typingopers (pvalsetlist .  1st)  ; 

typingopers (obj list . 1st)  ; 

typingopers (classlist. 1st)  ; 

typingopers (dblist. 1st) ;  /*  database  part  */ 

hidden 
op 

whattype;  val  type; 
eqtype:  type,  type  -*■  bool; 


axiom 

typingaxioms (bool) ; 
typingaxioms (nat) ; 
typingaxioms ( int)  ; 
typingaxioms (char) ; 
typingaxioms (str. char) ; 
typingaxioms ( intens)  ; 
typingaxioms (color) ; 
typingaxioms (pnt)  ; 
typingaxioms (ret)  ; 
typingaxioms ( form) ; 
typingaxioms (ptblt) ; 
typingaxioms (font)  ; 
typingaxioms (memid) ; 
typingaxioms ( regid) ; 
typingaxioms (stkid) ; 
typingaxioms (dregid) ; 
typingaxioms ( fid ) ; 
typingaxioms (memaddr) ; 
typingaxioms ( regaddr) ; 
typingaxioms (stkaddr) ; 
typingaxioms (dregaddr) ; 
typingaxioms (mattribute) ; 
typingaxioms (file) ; 
typingaxioms (mop) ; 
typingaxioms (dop) ; 
typingaxioms ( top)  ; 
typingaxioms (qop)  ; 
typingaxioms (sop)  ; 
typingaxioms (oop)  ; 
typingaxioms (rop) ; 
typingaxioms (bop) ; 
typingaxioms ( instr)  ; 

typingaxioms (pidlist . 1st) ;  /*  database  part  */ 

typingaxioms (pidsetlist . 1st) ; 

typingaxioms (vallist. 1st)  ; 

typingaxioms (valsetlist . 1st)  ; 

typingaxioms (proplist. 1st) ; 

typingaxioms (propsetlist. 1st) ; 

typingaxioms (pvallist. 1st)  ; 

typingaxioms ( pvalsetlist . 1st)  ; 

typingaxioms (obj list . 1st)  ; 

typingaxioms (classlist . 1st)  ; 

typingaxioms (dblist , 1st) ;  /*  database  part  */ 

equivrel (eqtype , type) ; 
end  extend; 
end  typing; 


spec  operators 
is 

extend 

opera tore lasses 
typing 
with 

primitive 

op 

boolnot:  -»■  m 
booland:  ^  d 
boolor:  do 

natpred:  -*■  m 
natsucc;  -<■  m 
natsum;  -►  do 
natsub  :  -*■  do 


a 

natlt:  -<■ 
intpred : 
intsucc : 
intabs ;  - 
intntoi : 
intiton : 
intsum;  - 
intsub;  - 
intmlt:  - 
intdiv:  - 
intmod;  - 


rop; 
->  mo 


intlt :  rop  ; 

chareq;  -»■  rop; 
chargt:  ->■  rop; 
charstrlen;  ^  mop; 
charmakestr:  -*•  mop; 
charheadstr:  mop; 

chartailstr:  ^  mop; 
charcatstr:  ^  dop; 
str. chareq;  ->■  rop; 
str. chargt;  -*•  rop; 
intenspred;  -<■  mop; 
intenssucc  ;  -*•  mop; 
intenssum;  ->■  dop; 
intenssub;  dop; 
intenseq;  ->-  rop; 
intensgt:  -*•  rop; 
colorredcompnt ;  ->■  mop 
colorgrncompnt ;  ->•  mop 
colorblucompnt :  ->■  mop 
colordef;  -*■  top; 
coloreq;  -*■  rop; 


pntxcord:  mop 

pntycord:  -*■  mop; 
pntloc:  ->■  dop; 
pntoffset:  ^  top; 
pnteq  :  ->•  rop ; 
pntgt:  ->■  rop; 
pntlt:  -*•  rop; 
pntge:  -*■  rop; 
pntle:  -»■  rop; 
rctorigin:  -►  mop; 
rctcorner:  ->■  mop; 
rctxdim:  -►  mop; 
rctydim;  ->•  mop; 
rctarea:  -<■  dop; 
ret  in:  dop  ; 

retdisj  :  ->  dop; 
ret  in  t:  ->■  dop; 
retput:  dop; 

rctshift:  ->■  top; 
forminit:  ->■  mop; 
formfarea:  mop; 

formgetcolor :  -►  dop; 
formfill:  ->■  dop; 
formsetcolor :  -*■  top; 
forminv;  -►  top; 
fontinit;  ->■  mop; 
fontret;  mop; 
fontlen;  -<■  mop; 
fontspmap:  -*•  dop; 
fontpsmap:  dop; 

fontin:  -*•  dop; 
fontdel:  ->•  dop; 
fontget;  -*  dop; 
fontset:  -»■  top; 
fontoffset:  qop; 

ptbltgetsrct :  -<■  mop; 
ptbltgetdrct :  ■*  mop; 
ptbltgetcrct :  -*■  mop; 
ptbltgetrule ;  ->•  mop; 
ptbltsetsrct :  ^  dop; 
ptbltsetdrct ;  dop; 
ptbltsetcrct :  ->  dop; 
ptbltsetrule ;  dop; 
ptbltcopy:  -*•  qop; 
ptbltdrawline :  -►  sop; 
ptbltfont:  ->■  sop; 
ptbltfontinv :  ^  oop; 

pidlist.eqlst :  ->•  rop;  /*  database  part  */ 

pidsetlist  .makenewlst :  -i-  mop; 

pidsetlist . unlst :  -►  dop; 

pidsetlist.  intlst :  dop; 

pidsetlist  .membl'st :  rop; 


*  «"•  -V 
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pidsetlist  .eqlst :  -►  rop; 
vallist . eqlst :  -*  rop; 
valsetlist .makenewlst :  ->•  mop; 
valsetlist .  unlst :  -►  dop; 
valsetlist .  intlst :  -*  dop; 
valsetlist  .memblst :  rop; 

valsetlist . eqlst ;  ^  rop; 
proplist .  f  irstlst :  mop; 

proplist .  restlst ;  -*■  mop; 
proplist . catlst :  ->■  dop; 
proplist. eqlst :  ^  rop; 
propsetlist  .makenewlst :  mop; 

propsetlist .  sof  irstlst :  mop; 

propsetlist. unlst :  -»■  dop; 
propsetlist .  intlst :  ->-  dop; 
propsetlist  .memblst :  -*•  rop; 
propsetlist .  eqlst :  ->•  rop; 
pval list .  f  irstlst :  mop; 

pva Ills t .  restlst ;  ->  mop; 
pvallist.  catlst :  ->  dop; 
pvallist  .memblst ;  rop; 
pvallist .  eqlst :  rop; 

pvalsetlist  .makenewlst :  -»•  mop; 
pvalsetlist .  sof  irstlst ;  -*■  mop; 
pvalsetlist .  unlst ;  -<■  dop; 
pvalsetlist .  intlst :  -►  dop; 
pvalsetlist  .memblst :  -*■  rop; 
pvalsetlist . eqlst :  rop; 

Ob j list .makenewlst :  ^  mop; 
obj  list .  sof  irstlst :  -*■  mop; 

Ob  j  list .  getlst :  dop; 

Ob  j  list .  eqlst :  -*•  rop; 

Ob  j  list  .memblst ;  rop; 

classlist  .makenewlst :  mop; 

classlist .  sof  irstlst :  mop; 

classlist .  unlst ;  ->-  dop; 
classlist .  intlst :  -*■  dop; 
classlist .  catlst :  dop; 

classlist .  deist ;  -*•  dop; 
classlist  .memblst ;  ->-  rop; 
classl ist . eqlst :  ->■  rop; 
dblist, makenewlst :  -►  mop; 
dblist .  sof  irstlst :  -*■  mop; 
dblist. catlst:  -<■  dop; 
dblist . deist :  ->.  dop; 
dblist .  intlst :  dop; 

dblist .modlst ;  ->■  top; 

dblist  .memblst :  rop;  /*  database  part  */ 

isbool:  -*■  bop; 
isnat ;  -«■  bop; 


2?5 
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isint:  ^  bop; 
is  char:  ->•  bop; 
isstr.char:  bop; 

isintens:  bop; 

iscolor:  ^  bop; 
ispnt;  bop; 
isrct;  bop; 
isform:  ^  bop; 
isptblt:  -*■  bop; 
isfont:  ->  bop; 
ismemid;  ->■  bop; 
isregid:  ->  bop; 
isstkid:  -*■  bop; 
isdregid:  ->■  bop; 
isfid;  bop; 
ismemaddr;  ->■  bop; 
isregaddr:  ^  bop; 
isstkaddr:  ->•  bop; 
isdregaddr;  -*■  bop; 
isfile:  bop; 

ismop:  -*■  bop; 
isdop;  -»■  bop; 
is  top:  bop; 

isqop:  -<■  bop; 
issop;  -I-  bop; 
isoop:  -►  bop; 
isrop:  bop; 

isbop:  -►  bop; 
isinstr:  ->■  bop; 
ispidlist .  1st :  ->■  bop; 
ispidsetlist ,  1st :  bop; 

isvallist. 1st:  >  bop; 
isvalsetlist . 1st :  -  bop; 
isproplist .  1st:  -<■  bop; 
ispropsetlist.lst:  bop; 

ispvallis  t .  1st :  -*■  bop; 
ispvalsetlist .  1st :  -*■  bop; 
isobj list . 1st :  -  bop; 
isclasslist .  1  St :  bop; 

isdblist .  1st :  -*■  bop; 


/*  database  part  */ 


hidden 

op 

applymop 
applydop 
apply top 
applyqop 
applysop 
applyoop 
applyrop 
applybop 


/*  database  part  */ 


mop,val  -*•  val; 

dop,val,val  val; 

top ,  val ,  val ,  val  val; 

qop ,  val ,  val ,  val ,  val  val; 

sop  ,  val ,  val ,  val ,  val ,  val ,  val  ->•  val; 

oop , val , val , val , val , val , val , val , val 

rop,val,val  -*•  val; 

bop,  val  ->•  val; 


axiom 

applymop (boolnot ( ) , v)  =  valofbool (not ( 
atomofbool (v) )  ) ; 

applydop (booland 0  , vl , v2)  =  valofbool (and ( 

atomofbool (vl) , atomofbool (v2) )  ) ; 
applydop (boolor 0  ,vl ,v2)  =  valofbool (or ( 

atomofbool (vl)  , atomofbool (v2) )  )  ; 

applymop (natpred 0  ,v)  =  valofnat (prednat ( 
atomofnat ( v) )  ); 

applymop (natsucc 0  ,v)  =  valofnat ( succnat ( 
atomof nat ( v) )  ); 

applydop (natsum 0 ,vl ,v2)  =  valofnat ( sumnat ( 
atomofnat (vl) , atomof nat (v2) )  ); 

applydop (natsub () ,vl ,v2)  =  valofnat ( subnat ( 
atomof nat (vl ), atomof nat (v2 ) )  ); 

applymop ( intpred () ,v)  =  valofint (predint ( 
atomof int ( v) ; 

applymop ( intsucc (), v)  =  valofint ( succint ( 
atomof int (v) ; 

applymop ( intabs () ,v)  =  valofint ( absint ( 
atomof int (v) ; 

applymop ( intntoi (), v)  =  valofint (ntoi ( 
atomofnat (v) )  ); 

applymop ( intiton 0 ,v)  =  valofnat ( iton ( 
atomof int (v) )  ) ; 

applydop ( intsum 0 ,vl ,v2)  =  valofint (sumint ( 
atomof int (vl)  , atomof int (v2)  )  ); 

applydop ( intsub 0  ,vl ,v2)  =  valofint (subint ( 
atomof int (vl) ,atomof int (v2) )  ) ; 

applydop ( intmlt 0  ,vl ,v2)  =  valofint (mltint ( 
atomof int (vl) , atomof int (v2 ) )  ); 
applydop ( intdiv 0  ,vl ,v2)  =  valofint (divint ( 
atomof int (vl) , atomof int (v2 ) )  ); 

applydop ( intmod (), vl , v2)  =  valofint (modint ( 
atomof int (vl) , atomof int (v2 ) )  ) ; 

applymop (charstrlen () ,v)  =  valofnat ( lenstr . char ( 
atomof str .char (v) )  ); 

applymop (charmakestr (), v)  =  valof str . char ( 
makestr .char (atomofchar (v) )  ); 
applymop ( charheadstr (), v)  =  valofchar (headstr . char ( 
atomof str . char (v) )  ); 

applymop ( chartailstr (), v)  =  valof str . char ( 

tailstr .char (atomofstr. char (v) )  ) ; 

applydop ( charcatstr 0, vl , v2 )  =  valof str . char ( 
catstr . char (atomof str . char (vl )  , 
atomof s  tr . char ( v2) 

)); 

applymop ( intenspred (), V )  =  valof intens ( 
precintens (atomof intens (v) : 
applymop ( intenssucc (), v)  =  valofintens( 
succintens (atomof intens (v) ; 


applydopCintenssumO  ,vl,v2)  =  valofintens( 
sumintens (atomof intens (vl) , 
atomof intens (v2) 

)  )  ; 

applydopdntenssub  0  ,vl,v2)  =  valof intens  ( 
subintens (atomof intens (vl) , 
atomof intens (v2) 

)  )  ; 

appiymop ( colorredcompnt ( ) , v)  =  valofintens( 
redcompnt (atomof color (v) )  ); 
appiymop (colorgrncompnt () ,v)  =  valofintens ( 
grncompnt (atomof color (v) )  ) ; 
appiymop ( CO lorblucompnt 0, v)  =  valofintens ( 
blucompnt (atomof color (v) )  ); 
applytop ( colordef ( ) , vl , v2 , v3)  =  valofcolor( 
def color (atomof intens (vl )  , 
atomofintens (v2) , 
atomofintens (v3) 

)  )  ; 

appiymop (pntxcord 0  ,v)  =  valof int (xcord ( 

atomofpnt(v) )  ) ; 

appiymop (pntycord (), v)  =  valof int (ycord ( 

atomofpnt ( v)  )  )  ; 

applydop (pntloc ( ) , vl , v2)  =  valof pnt ( locpnt { 
atomof int (vl) , atomof int (v2) )  ); 
applytop (pntoffset 0  ,vi ,v2 ,v3)  =  valofpnt( 
of fsetpnt (atomof int (vl) , 
atomofpnt ( v2) , 
atomofpnt (v3 ) 

)  )  ; 

appiymop (rctorigin 0 ,v)  =  valofpnt (origin ( 
atomof ret ( v) )  ) ; 

appiymop ( rctcorner 0  ,v)  =  valof pnt (corner ( 
atomof ret ( v) )  ) ; 

appiymop (rctxdim( ) ,v)  =  valof int ( xdimret ( 
atomof ret (v) )  ); 

appiymop (rctydim 0, v)  =  valof int (ydimret ( 
atomofret ( v) )  ); 

applydop ( rctarea () ,vl ,v2)  =  valof ret ( area ( 
atomofpnt (vl)  , atomofpnt (v2) )  )  ; 

applydop (rctin () ,vl ,v2)  =  valofbool ( inret ( 
atomofpnt (vl) , atomof ret (v2)  )  ); 
applydop(rctdisj 0  ,vl, v2)  =  valofbool (disjrct ( 
atomof ret (vl) , atomof rot (v2) )  ) ; 
applydopKretint ( ) , vl , v2)  =  valof ret ( intsetret ( 
atomofret (vl) , atomofret (v2) )  ); 

applydop (retput 0 ,vl ,v2)  =  valof ret (putret ( 
atomofpnt (vl) , atomofret (v2) )  ); 

applytop (rctshift 0  ,vl ,v2 ,v3)  =  valof ret (shif tret ( 
atomof int (vl)  , 
atomof int (v2) , 
atomof int (v3) , 

)  )  ; 


applymop ( f orminit { ) , v)  =  valof f orm ( initf orm ( 
atomof ret ( v) )  ); 

applymop ( formf area {), v)  =  valof ret { f area ( 
atomof form (v) )  ) ; 

applydop (formgeteolor ( ) , vl , v2)  =  valofeolor( 

geteolor (atomofpnt (vl) , atomof form (v2 ) )  ) ; 

applydop ( formf ill {) ,vl ,v2)  =  valof form ( filiform ( 
atomof eolor (vl) ,atomof form(v2) )  ) ; 

applytop ( formseteolor { ) , vl , v2 , v3)  =  valofform( 
seteolor (atomofpnt (vl) , 
atomof pnt (v2 ) , 
atomofpnt ( v3 ) 

)  )  ; 

applytop ( forminv 0  ,vl ,v2 ,v3)  =  valofform( 
invform(atomofeolor (vl) , 
atomof eolor (v2 ) , 
atomofeolor (v3) 

)  )  ; 

applymop ( fontinit (), v)  =  valof font ( initfont ( 
atomof ret ( v) )  ); 

applymop ( fontret 0 ,v)  =  valof ret ( retfont ( 
atomof font (v)  )  ); 

applymop ( fontlen (), v)  =  valof nat ( lenfont ( 
atomof font (v) )  ) ; 

applydop ( fontspmap () ,vl ,v2)  =  valof pnt ( spmap ( 
atomofret (vl) , atomofpnt (v2) )  ); 
applydop ( fontpsmap 0, vl ,v2)  =  valofpnt (psmap ( 
atomof ret (vl) , atomofpnt (v2) )  ) ; 
applydop ( fontin () ,vl , v2)  =  valofbool ( infont ( 
atomofnat ( vl) , atomof font (v2) )  ) ; 

applydop ( fontdel 0  ,vl ,v2)  =  valof font (delfont ( 
atomofnat (vl) ,atomof font (v2) )  ) ; 

applydop ( fontgetfont 0 ,vl , v2 )  =  valof form ( getfont ( 
atomofnat (vl) ,atomof font (v2) )  ) ; 

applytop ( fontset () ,vl , v2 ,v3)  =  valof font ( setfont ( 
atomof form (vl) , 
atomofnat ( v2) , 
atomof font (v3) 

)  )  ; 

applyqop ( fon toff set  0  ,vl ,v2 ,v3 , v4 )  =  valofpnt( 
of fsetfont (atomof int (vl) , 
atomof int (v2) , 
atomof font (v3) , 
atomofpnt (v4) 

)  )  ; 

applymop (ptbltgetsret (), v)  =  valof ret (getsret ( 
atomofptblt (v)  )  )  ; 

applymop ( ptbltgetdret 0  ,v)  =  valof ret (getdret ( 
atomofptblt (v) )  ); 


applymop {ptbltgetcrct 0 , v)  =  valof ret (getcrct { 
atomofptblt ( v) )  ); 

applymop (ptbltgetrule 0 ,v)  =  valof nat ( getrule ( 
atomofptblt (v) )  ) ; 

applydop (ptbltsetsrct ( ) , vl , v2)  =  valofptblt( 

setsret (atomof ret ( vl) , atomofptblt (v2 ) )  ) ; 
applydop (ptbltsetdret 0  ,vl ,v2)  =  valofptblt( 

setdret (atomofret ( vl) , atomofptblt (v2 ) )  ) ; 
applydop (ptbltsetoret 0  ,vl ,v2)  =  valofptblt( 

seteret (atomofret (vl) , atomofptblt (v2) )  ) ; 
applydop (ptbltsetrule 0  ,vl ,v2)  =  valofptblt( 

setrule (atomofnat (vl) , atomofptblt (v2 ) )  ) ; 
applyqop(ptblteopy() ,vl,v2,v3,v4)  =  valofform( 
eopyblt (atomofptblt (vl) , 
atomof form (v2) , 
atomof form (v3) , 
atomof form (v4 ) 

)  )  ; 

applysop (ptbltdrawline ( ) , vl , v2 , v3 , v4 , v5 , v6 )  = 
valofform(drawline (atomofpnt (vl)  , 

atomof pnt { v2 ) , 
atomofblt ( v3 ) , 
atomof form (v4 ) , 
atomof form {v5 ) , 
atomof form (v6) 

)  )  ; 

applysop (ptbltfont ( ) , vl , v2 , v3 , v4 , v5 , v6 )  = 
valof form (copy font (atomofpnt { vl)  , 

atomofptblt (v2) , 
atomofnat (v3) , 
atomof font ( v4 ) , 
atomof form (v5 ) , 
atomof form (v6 ) , 

)  )  ; 

applyoop (ptbltfontinv ( ) , vl , v2 , v3 , v4 , v5 , v6 , v7 , v8 )  = 
valof form (inveopy font (atomof color ( vl) , 

atomof color (v2 ) , 
atomofpnt (v3) , 
atomofptblt (v4 ) , 
atomofnat { v5 ) , 
atomof font (v6)  , 
atomof form (v7) , 
atomof form ( v8) 

)  )  ; 

applymop(pidsetlist.make'iewlst  ()  ,v)  = 

valof pidset list  vpidsetlist .makenewlst ( 
atomofpidlist ( v) 

) ) ;  /*  database  part  */ 

applydop (pidsetlist.unlst ( ) ,vl,v2)  = 

valof pidset list (pidsetlis  t. unlst ( 
atomofpidsetlist (vl) , 
atomofpidsetJList  (v2 ) 


applydop (pidsetlist.intlst() ,vl,v2)  = 

valofpidsetlist(pidsetlist.intlst( 
atomofpidsetlist { vl)  , 
atomofpidsetlist (v2 ) 

)  )  ; 

applymop ( valsetlis t .makenewlst ( ) ,v)  = 

valofval set list (valsetlist .makenewlst ( 
atomofvallist ( v) )  ); 

applydop (valsetlist . unlst ( ) ,vl,v2)  = 

valofval setlist (valsetlist.unlst( 
atomofvalsetlist ( vl)  , 
atomofvalsetlist (v2) 

)  )  ; 

applydop { valsetlist . intlst ( ) ,vl,v2)  = 

atomofvalsetlist (valsetlist . intlst ( 
atomof valsetlist (vl ) , 
atomofvalsetlist (v2) 

)  )  ; 

applymop (propiist . firstlst 0, v)  =  valof pidlist ( 
proplist . f irstlst (atomofproplist ( v)  )  ); 

applymop (propiist . restlst 0, v)  =  valofvalsetlist ( 
proplist . restlst (atomofproplist (v) )  ) ; 

applydop (propiist . catlst 0  ,vl ,v2)  =  valof proplist ( 
proplist . catlst (atomof pidlist (vl) , 

atomofvalsetlist (v2 ) 

)  )  ; 

applymop (propsetlist .makenewlst ( ) ,v)  = 

valofpropsetlist (propsetlist. makenewlst ( 
atomof proplist (v)  )  )  ; 

applymop (propsetlist. sofirstlst 0  ,v)  = 

valofpidsetlist (propsetlist . sofirstlst ( 
atomof propsetlist (v)  )  ); 

applydop (propsetlist . unlst ( ) ,vl,v2)  = 

valofpropsetlist (propsetlist . unlst ( 
atomof propsetlist (vl) , 
atomof propsetlist (v2) 

)  )  ; 

applydop (propsetlist . intlst ( ) ,vl,v2)  = 

valofpropsetlist (propsetlist . intlst ( 
atomofpropsetlist ( vl)  , 
atomofpropsetlist ( v2) 

)  )  ; 

applymop ( pvallist . firstlst (), v)  =  valofpidlist ( 
pvallist .firstlst (atomof pvallist (v) )  ); 

applymop (pvallist . restlst 0  ,v)  =  valofvallist ( 
pvallist . restlst ( atomof pvallist (v)  )  )  ; 

applydop (pvallist. catlst () ,vl ,v2)  =  valofpvallist ( 
pvallist .catlst (atomof pidlist (vl) , 
atomofvallist (v2) 


applymop (pvalsetlist .makenewlst ( ) ,v)  = 

pvalsetlist .makenewlst (atomofpvallist (v) )  ) 
applymop (pvalsetlist . sofirstlst ( ) ,v)  = 

valofpidsetlist (pvalsetlist . sofirstlst ( 
atomofpvalsetlist (v) )  ); 
applydop (pvalsetlist .unlst ( ) ,vl,v2)  = 

valof pvalsetlist (pvalsetlist , unlst ( 
atomofpvalsetlist (vl) , 
atomofpvalsetlist (v2) 

)  )  ; 

applydop (pvalsetlist . intlst ( ) ,vl,v2)  = 

valof pvalsetlist (pvalsetlist . intis t ( 
atomofpvalsetlist (vl) , 
atomofpvalsetlist (v2) 

))  ; 

applymop (obj list .makenewlst 0  ,v)  =  valofob j list ( 

obj list .makenewlst (atomofpvalsetlist (v) )  ) ; 
applymop (obj list. makenewlst 0 ,v)  =  valofpvalsetlist ( 
obj list .makenewlst (atomof obj list (v) )  ) ; 
applymop (obj list , sofirstlst () ,v)  =  valofpidsetlist ( 
obj list . sofirstlst (atomofob j list ( v)  )  ) ; 
applydop (obj list .getlst 0  ,vl , v2)  =  valofvallist ( 
obj list.getlst (atomofobj list (vl) , 
atomofpidlist (v2) , 

))  ; 

applymop  (classlist. makenewlst  (,)  ,v)  = 

valof classli St (c las slist .makenewlst ( 
atomofpidsetlist ( v) )  ) ; 
applymop (classlist . sofirst . 1st ( ) ,v)  = 

valofpidsetlist (classlist. sofirstlst ( 
atomof classlist (v) )  ); 

applydop (classlist . unlst 0 ,vl ,v2)  =  valof classlist ( 
classlist . unlst (atomof classlist (vl)  , 
atomofclasslist (v2) 

)  )  ; 

applydop (classlist . intlst ( ) ,vl,v2)  = 

va lofc la sslist (classlist. in tlst( 
atomofclasslist (vl) , 
atomof classlist (v2) 

)  )  ; 

applydop (classlist . catlst ( ) ,vl,v2)  = 

va lofc la sslist (classlist. catlst ( 
atomofclasslist (vl) , 
atomofobj list (v2) 

)  )  ; 

applydop (classlist .deist ( ) ,vl,v2)  = 

valofclasslist (classlist .deist ( 
atomofob j list (vl) , 
atomofclasslist ( v2 ) 


applymop (dblist .makenewlst ( ) , v)  = 

valofdblist (dblist .makenewlst ( 
atomof classlist ( v)  )  ); 
applymop (dblist . sofirstlst ( ) ,v)  = 

valofpidsetlist (dblist . sofirstlst ( 
atomof dblist (v) )  ); 

applydop (dblist . catlst 0  ,vl, v2)  =  valofdblist( 
dblist . catlst (atomof dblist (vl) , 

atomofclasslist (v2) 

) )  ; 

applydop(dblist. deist  0 ,vl,v2)  =  valofdblist( 
dblist . deist (atomof classlist (vl) , 
atomofdblist (v2) 

)); 

applydop (dblist . intlst 0 ,vl ,v2)  = 

valofpval set list (dblist. intlst( 
atomofdblist (vl) , 
atomofclasslist (v2) 

)  )  ; 

applydop(dblist.retobjlst ( ) ,vl,v2)  = 

valofobjlist (dblist. retobjlst ( 
atomofdblist (vl) , 
atomofpvallist (v2) 

)  )  ; 

applytop(dblist.modlst 0  ,vl,v2,v3)  = 
valofdblist (dblist , modi St ( 
atomofdblist (vl) , 
atomofob j list (v2) , 
atomofpvallist (v3) 

) ) ;  /*  database  part  */ 

relop (nat , eq) ; 

relop (nat ,gt) ; 

relop (nat , It) ; 

relop (int , eq) ; 

relop(int,gt) ; 

relop ( int , It )  ; 

relop(char,eq)  ; 

relop (char ,gt)  ; 

relop (str . char ,eq)  ; 

relop (str. char, gt)  ; 

relop ( intens , eq) ; 

relop ( intens , gt) ; 

relop ( intens , It ) ; 

relop(colorkeq) ; 

relop (pnt , eq) ; 

relop(pnt,gt) ; 

relop (pnt , It) ; 

relop (pnt , ge) ; 

relop (pnt , le) ; 


/*  database  part  */ 


relop(pidlist,eqlst) ; 
relop (pidsetlist , eqlst)  ; 
relop(vallist,eqlst) ; 
relop (valsetlist , eqlst)  ; 
relop (proplist , eqlst) ; 
relop (propsetlist, eqlst)  ; 
relop (pvallist, eqlst)  ; 
relop (pvalsetlist, eqlst) ; 
relop (obj list , eqlst) ; 
relop (classlist, eqlst) ; 
relop (dblist , eqlst) ; 
relop(pidsetlist,memblst) ; 
relop  (valsetlist  jUiemblst)  ; 
relop (propsetlist ,memblst) ; 
relop(pvallist,meinblst)  ; 
relop  (pvalsetlist  ,meinblst)  ; 
relop (classlist ,memblst) ; 
relop (dblist .memblst) ;  /*  database  part  */ 

isops (bool) ; 
isops (nat) ; 
isops ( int) ; 
isops (char) ; 
isops (str . char) ; 
isops ( intens)  ; 
isops ( color) ; 
isops (pnt)  ; 
isops (ret)  ; 
isops ( form) ; 
isops (ptblt) ; 
isops (font)  ; 
isops (memid) ; 
isops (regid) ; 
isops (stkid) ; 
isops (dregid) ; 
isops (fid) ; 
isops (memaddr) ; 
isops ( regaddr)  ; 
isops ( stkaddr) ; 
isops (dregaddr) ; 
isops ( file)  ; 
isops (mop) ; 
isops (dop) ; 
isops (top) ; 
isops (qop)  ; 
isops (sop) ; 
isops (oop) ; 
isops (rop) ; 
isops (bop) ; 
isops ( instr) ; 


/*  database  part  */ 


isops(pidlist.lst) ; 
isops (pidsetlist . Istl ; 
isops ( vallist.lst) ; 
isops (valsetlist. 1st)  ; 
isops (proplist. 1st)  ; 
isops (propsetlist . 1st) ; 
isops (pvallist. 1st)  ; 
isops (pvalsetlist . 1st) ; 
isops (obj list . 1st) ; 
isops (classlist. 1st) ; 
isops (dblist . 1st) ;  /*  database  part  */ 

end  extend; 
end  operators; 


spec  instructions 
is 

extend 

natural , 
integer , 
memaddress , 
regaddress , 
stkaddress , 
dregaddress , 
operatorclasses , 
instructiontype , 
typing, 
qaddress 
with 

primitive 

op 

org :  -►  instr; 

extern:  instr; 

globl:  instr; 

mbegin;  ->■  instr; 

mend:  -*•  instr; 

offst:  int,regaddr  -*■  instr; 

link:  regaddr,nat  h-  instr; 

unlink;  regaddr,nat  -<■  instr; 

getdwin;  dregaddr ,  regaddr  instr; 

setdwin;  regaddr , dregaddr  -►  instr; 

getmtr;  mattribute ,  regaddr  -»■  instr; 

setmtr:  mattribute , regaddr  -*•  instr; 

raodads;  mop, regaddr  -►  instr; 

monad:  mop, regaddr , regaddr  instr; 

monadi;  mop , val , regaddr  instr; 

dyads:  dop , regaddr , regaddr  instr; 

dyadsi:  dop,  val ,  regaddr  -*•  instr; 

dyad:  dop ,  regaddr ,  regaddr ,  regaddr  -*•  instr; 

dyadi  :  dop ,  val ,  regaddr ,  regaddr  instr; 


triads:  top,regaddr ,regaddr,regaddr  instr; 
triads!;  top , val , regaddr , regaddr  instr; 

triad:  top , regaddr , regaddr , regaddr , regaddr  ^  instr; 
triad!  :  top ,  val ,  regaddr  ,  regaddr  ,  regaddr  instr; 

quads:  qop ,  regaddr ,  regaddr ,  regaddr  ,  regaddr  instr; 
quad :  qop , regaddr , regaddr , regaddr , regaddr , 
regaddr  -*■  instr; 

sexads :  sop , regaddr , regaddr , regaddr , regaddr , 
regaddr , regaddr  ->■  instr; 
sexad :  sop , regaddr , regaddr , regaddr , regaddr , 
regaddr , regaddr, regaddr  instr; 
octads :  sop , regaddr , regaddr , regaddr , regaddr , 

regaddr  ,  regaddr  ,  regaddr  ,  regaddr  ->■  instr; 
octad ;  sop , regaddr , regaddr , regaddr , regaddr , regaddr , 
regaddr ,  regaddr ,  regaddr  ,  regaddr  ->■  instr; 
val,memaddr  instr; 
inovi_pcr:  val,int  -*■  instr; 
movi_r:  val,  regaddr  ->  instr; 
movi_ri:  val,  regaddr  -*■  instr; 
movi_rid:  val ,  regaddr ,  int  ->■  instr; 
movi_ridn :  val , regaddr ,nat , int  ^  instr; 
mov_m_m:  memaddr ,memaddr  -*■  instr; 
mov_m_r ;  memaddr , regaddr  ^  instr; 
mov_m__ri:  memaddr , regaddr  ^  instr; 
mov_m_rid:  memaddr , regaddr , int  ^  instr; 
mov_m_ridn;  memaddr , regaddr  ,nat ,  int  instr; 
mov_m_d:  memaddr , dregaddr  instr; 

mov_pcr_pcr:  int,  int  -<■  instr; 
mov_pcr_r :  int, regaddr  ^  instr; 
mov_pcr_ri :  int,  regaddr  instr; 

mov_pcr_rid:  int ,  regaddr ,  int  instr; 

mov_pcr_ridn :  int, regaddr, nat, int  instr; 

mov_pcr_d;  int, dregaddr  ^  instr; 
mov_r_m:  regaddr , memaddr  instr; 

mov_r_pcr:  regaddr,  int  ->•  instr; 
mov_r_r:  regaddr , regaddr  -*■  instr; 
mov_r_ri  ;  regaddr , regaddr  -*  instr; 
mov_r_rid:  regaddr, regaddr, int  ->■  instr; 
mov_r_ridn:  regaddr ,  regaddr ,  nat ,  int  instr; 
mov_r_d;  regaddr ,  dregaddr  -<■  instr; 
mov_ri_m;  regaddr , memaddr  -*•  instr; 
mov_ri_pcr:  regaddr, int  ^  instr; 
mov_ri_r:  regaddr , regaddr  -<■  instr; 
mov_ri_ri:  regaddr , regaddr  -*•  instr; 
mov_ri_rid:  regaddr , regaddr , int  -*■  instr; 
mov_ri_ridn:  regaddr , regaddr , nat ,  int  ->■  instr; 
mov_ri__d:  regaddr , dregaddr  -*■  instr; 
mov_rid_m:  regaddr , int , memaddr  instr; 

mov_rid_pcr:  regaddr , int , int  -*•  instr; 
mov_rid_r:  regaddr , int , regaddr  instr; 
mov_rid_ri;  regaddr , int , regaddr  instr; 


mov_rid_rid :  regaddr ,  int ,  regaddr ,  int  ->■  instr; 
mov_rid_ridn :  regaddr ,  int , regaddr , nat,  int  -►  instr; 
inov_rid_d:  regaddr , int , dr egaddr  instr; 
mov_ridn_m;  regaddr ,  nat ,  int  ,memaddr  -»■  instr; 
mov_ridn_pcr :  regaddr ,  nat ,  int ,  int  instr; 
mov_ridn_r:  regaddr, nat, int, regaddr  -»■  instr; 
niov_ridn_ri  ;  regaddr, nat , int, regaddr  ^  instr; 
mov_ridn_rid :  regaddr ,  nat ,  int ,  regaddr ,  int  instr; 

mov_ridn_ridn :  regaddr ,  nat ,  int ,  regaddr ,  int ,  int  ->• 

instr; 

mov_ridn_d;  regaddr , nat , int , dregaddr  instr; 

mov_d_m:  dregaddr ,meinaddr  -*•  instr; 

mov_d_pcr;  dregaddr,  int  instr; 

mov_d_r  :  dregaddr  ,  regaddr  ->■  instr; 

mov_d_ri  :  dregaddr , regaddr  ->■  instr; 

inov_d_rid:  dregaddr, regaddr, int  -»■  instr; 

mQv_d_ridn;  dregaddr ,  regaddr  ,  nat ,  int  -*■  instr; 

mov_d_d:  dregaddr , dregaddr  instr; 

push_i  :  val ,  stkaddr  ->•  instr; 

push_m;  memaddr , stkaddr  instr; 

push_pcr:  int,  stkaddr  instr; 

push_r:  regaddr , stkaddr  -*■  instr; 

push_ri:  regaddr , stkaddr  -»•  instr; 

push_rid:  regaddr ,  int ,  stkaddr  instr; 

push_ridn;  regaddr , nat,  int ,  stkaddr  instr; 

push_d:  dregaddr , stkaddr  instr; 

pop_x;  stkaddr  instr; 

pop_m:  stkaddr , memaddr  instr; 

pop_pcr:  stkaddr, int  instr; 

pop_r:  stkaddr , regaddr  instr; 

pop_ri:  stkaddr , regaddr  -*•  instr; 

pop_rid:  stkaddr , regaddr , int  ->■  instr; 

pop_ridn:  stkaddr ,  regaddr ,  nat ,  int  -►  instr; 

pop_d:  stkaddr , dregaddr  -►  instr; 

nop:  ->•  instr; 

stop:  -*•  instr; 

jmp:  memaddr  instr; 

jmp_i:  memaddr  instr; 

jmp__r:  regaddr  instr; 

bra:  int  >  instr; 

bra_r:  regaddr  -*■  instr; 

if;  relop,  regaddr,  regaddr,  memaddr  instr; 

ifi:  relop ,  regaddr ,  val , memaddr  -*■  instr; 
ifte:  relop,  regaddr  ,  regaddr  ,  memaddr ,  memaddr  instr; 

iftei:  re  lop ,  regaddr ,  val ,  memaddr ,  memaddr  -►  instr; 
if_pcr:  relop,  regaddr , regaddr ,  int  ->  instr; 
ifi_pcr:  relop, regaddr , val , int  instr; 

ifte_pcr:  relop , regaddr , regaddr , int , int  -+  instr; 
iftei_pcr:  relop,  regaddr ,  val ,  int ,  int  ->■  instr; 
test:  bop,  regaddr ,  memaddr  •+  instr; 
testm:  bop, memaddr , memaddr  ->■  instr; 


teste :  bop ,  regaddr  ,memaddr  ,meinaddr 
testme :  bop,memaddr ,memaddr ,memaddr 
test_pcr:  bop ,  regaddr ,  int  -*■  instr; 
testm_pcr:  bop,memaddr ,  int  -*•  instr; 
teste_pcr:  bop  ,  regaddr  ,  int ,  int  ■+  instr; 

instr; 


instr ; 
instr ; 


testme_pcr:  bop ,memaddr , int , int 
jsr;  memaddr , stkaddr  -*■  instr; 


jsr_i:  memaddr  ,  stkaddr  -► 
jsr_r:  regaddr ,  stkaddr 
bsr:  int,  stkaddr  instr; 
bsr_r:  regaddr  ,  stkaddr 
rts :  stkaddr  -<■  instr; 
open:  stkaddr  instr; 
close:  stkaddr  ->•  instr; 
read:  stkaddr  ^  instr; 
write:  stkaddr  ^  instr; 


instr ; 
instr ; 


instr ; 


write_i : 
write_m: 
write_r : 
delete  x; 


val,qaddr  -*■  instr; 
memaddr  ,qaddr  instr; 
regaddr  ,qaddr  -»•  instr; 
qaddr  instr; 


/ 

/* 


delete 

delete 


m; 
r ; 


qaddr 

qaddr 


instr ; 
instr; 


read_m:  qaddr , memaddr  instr;  /’ 


read_r:  qaddr , regaddr 
open:  val  -»■  instr; 
close:  val  instr; 


instr ; 


end  extend; 
end  instructions; 


database  part 
write  to  queue 


V 

*/ 


delete  value 
from  queue  */ 


read  value  from 
queue  */ 


/*  open  database  */ 
/*  close  database  */ 
/*  database  part  */ 


spec  amstate 
is 

extend 

boolean , 
natural , 
integer , 
str . chartype , 
memaddress , 
regaddress , 
stkaddress , 
dregaddress , 
files , 

identifiers , 
typing, 


state ; 
pri-niwive 

fetchm:  memaddr ,  state  -<•  val;  /*  memory  */ 

fetchr:  regaddr ,  state  -»■  val;  /*  register  */ 

fetchd:  dregaddr ,  state  val;  /*  display  register  */ 
fetchdwin:  dregaddr , state  -*•  val; 

/*  display  window  */ 
fetchmtr:  mattribute, state  ^  val; 

/*  monitor  attribute  */ 
storem:  val ,  memaddr ,  state  -»■  state; 
storer:  val ,  regaddr ,  state  state; 

stored:  val , dregaddr , state  -►  state; 
storedwin:  val ,  dregaddr  ,  state  state; 
storedmtr;  val , mattribute , state  -<•  state; 

initam:  ->  state;  /*  initialize 

machine  */ 

initstk;  stkaddr, state  ^  state; 

/*  initialize  stack  */ 

topstk:  stkaddr , state  val;  /*  get  top  val  of 

stack  */ 

pushstk;  val ,  stkaddr ,  state  -*•  state; 

/*  push  stack  */ 

popstk:  stkaddr , state  ->•  state;  /*  pop  stack  */ 
lalloc:  nat , state  ^  memid;  /*  get  memory  block 

from  heap  */ 

ifree:  memid, state  -*•  state;  /*  free  memroy  block  */ 

indir:  nat, memaddr  ^  memaddr;  /*  memaddr  for  n 

levels  of 
indirection  */ 

infile:  file, state  ^  val;  /*  read  from  file  */ 

outfile:  val ,  file ,  state  state; 

/*  write  to  file  */ 

openfile:  str . char , file, int , int , state  -’■  state; 

/*  open  file  */ 

closefile:  file, state  ^  state;  /*  close  file  */ 
rmode :  ->  int;  /*  read  mode  */ 


wmode ;  ->■  int ; 

/* 

write  mode  */ 

rwmode :  ^  int; 

/* 

read/write  mode 

openerr:  -»•  int; 

/* 

open  error  */ 

openok:  ->int; 

/* 

open  ok  */ 

valdata:  int; 

/* 

file  ops  w/  AM 
sort  val  data  * 

chardata:  ^  int; 

/* 

file  ops  w/ 

character  data  */ 

/*  database  part  */ 

/*  initialize  queue  */ 
/*  read  front  value 
from  queue  */ 


initq:  qaddr, state  state; 
read;  qaddr, state  val; 


write:  val  ,qaddr ,  state  -►  state; 

/*  write  to  queue  */ 

delete:  qaddr, state  ->■  state;  /*  delete  front  value 

from  queue  */ 

open:  db ,  str .  char ,  state  state; 

/*  open  database  */ 
close:  db , str . char, state  state; 

/*  close  database  */ 
/*  data  base  part  */ 

hidden 

op 

y**************************************** 

*  active  -  lalloc  flag 

*  true  when  memory  block  is  allocated  w/  lalloc 

*  false  initially  and  after  memory  block 
released  with  Ifree 

*  used  to  prevent  offsetting  into  non- 
allocated  memory 

*/ 

active:  memid, state  bool; 
axiom 

if  whattype{v)  !=  formtypeO  then 
stored (v ,a ,q)  =  undef; 
endif ; 

if  whattype(v)  !=  pnttypeO  then 
storedwin (v,a,q)  =  undef; 
endif ; 

if  whattype(v)  !=  nattype ( ) 
then 

storemtr ( V , xpixels ( ) ,q)  =  undef; 
storemtr (v,ypixels 0 ,q)  =  undef; 
storemtr (v,hscrnsi2e 0  ,q)  =  undef; 
storemtr (v,vscrnsi2e 0  ,q)  =  undef; 
storemtr (v, intenscapbl 0 ,q)  =  undef; 
storemtr (v , colorcapbl 0 ,q)  =  undef; 
endif ; 

if  whattype(v)  !=  colortypeO  then 
storemtr (v,backgnd () ,q)  =  undef; 
endif ; 

if  whattype(v)  1=  dregaddr ( )  then 
storemtr (v,dselect () ,q)  =  undef; 
endif; 

topstk ( s , initstk ( s) )  =  undef; 
popstk (s , initstk (s) )  =  undef; 
popstk { s , initam ( ) )  =  undef; 
stateaxioms (m,memaddr) ; 
stateaxioms ( r , regaddr) ; 
stateaxioms (d , dregaddr)  ; 
stateaxioms (dwin , dregaddr)  ; 
stateaxioms (mtr ,mattribute) ; 


topstk ( s ,pushstk ( V, s ,q) )  =  v; 

popstk (s , pushstk (v, s ,q) )  =  q; 

active (m, initam 0 )  =  false; 

active ( lalloc (n ,q) ,q)  =  true; 

active (m, If ree (m, q) )  =  false; 

active (m, storer (v, a ,q) )  =  active(m,q); 

active (m, storem (v , a, q) )  =  active(m,q); 

active (m, stored (v, a ,q) )  =  active(m,q); 

active (m, storedwin (v, a, q) )  =  active(m,q); 

active (m, storexscrnsize (v, a, q) )  =  active (m,q) ; 

active (m, storeyscrnsize (v, a, q) )  =  active(m,q); 

active  (m,  storeintenscapbKv,  a  ,q)  )  =  active(m,q); 

active (m, storecolorcapbl (v, a ,q) )  =  active(m,q); 

active (m, storebackgnd (v, a ,q) )  =  active(m,q); 

active (m, storedregaddr(v, a, q) )  =  active(m,q); 

active (m, initstk (a ,q) )  =  active(m,q); 

active (m, pushstk (v , a ,q) )  =  active(m,q); 

active {m, popstk (a,q) )  =  active (m,q) ; 

active (m, outfile (v, f ,q) )  =  active(m,q); 

active (m,openfile (s , f,x,y,q) )  =  active(m,q); 

active {m, closefile ( f ,q) )  =  active(m,q); 

if  active  (m,q)  =  falseO  then 

fetchm(of fset (n,m) ,q)  =  undef ; 
endif ; 

if  active(m,q)  =  falseO  then 

storem(offset(n,m) ,q)  =  undef; 
endif ; 

if  Itint  (n,ntoi  (n2)  )  =  trueO 
then 

offset (n,offset(nl , startmemaddr ( 
lalloc (n2 ,q) )  ) )  = 
offset ( 

siimint  (n  ,nl)  , 

startmemaddr ( lalloc (n2 ,q) ) 

)  ; 

else 

offset(n, offset (nl, startmemaddr ( lalloc (n2 ,q) )  ) ) 
undef; 

indir (zeronat ( ) ,m)  =  m; 

if  whattype ( fetchm (indir (n ,m) ,q) )  =  typememaddr ( ) 
then 

indir (succnat (n) ,m)  =  atomofmemaddr ( 
fetchm(indir (n,m)  ,q)  )  ; 

else 

indir (succnat (n) ,m)  =  undef; 
endif; 

openf ile ( s , f , n ,openf ile (s , f ,m,x ,q) )  =  undef; 
closef ile ( f ,openf ile (s, f ,n,x, q) )  =  q; 
inf ile ( f , initam () )  =  undef; 
inf ile ( f , close (d,q) )  =  undef; 

inf ile ( f ,openf ile (s , f ,wmode ( ) ,x,q) )  =  undef; 


outf ile ( V, f , initam ( ) )  =  undef; 

outf ile (v , f , close ( f ,q) )  =  undef; 

outf ile (v , f ,openf ile (s , f , rmode () ,x ,q) )  =  undef; 

out  file ( f , openf ile ( s , f ,m, chardata (), q)  )  =  undef; 

/*  database  part  */ 

read (qu, initq (qu, q)  )  =  undef;  /*  qu :  queue  */ 
delete (qu , initam () )  =  undef; 

/*  q:  state  */ 

delete (qu, write (v,qu, ini tq(qu,q) ) )  =  v; 

/*  v:  value  */ 

read (qu , write (v ,qu, initq (qu,q) ) )  =  v; 

delete  (write  (v ,  qu ,  initq  0)  )  =  initq(); 

delete (write (v,qu,q)  )  =  write (v , qu , delete (qu , q) )  ; 

if  not  (initqO)  =  trueO 

then 

read (qu , write (v ,qu,q) )  =  read(qu,q); 
endif ; 

active (m, initq (a ,q) )  =  active(m,q); 
active (m, write (v , a , q) )  =  active(m,q); 
active (m, delete ( a ,q) )  =  active(m,q); 
active (m,open(s ,d,q) )  =  active(m,q); 

/*  s:  string  char  */ 
active (m, close ( s , d ,q) )  =  active(m,q); 

/*  d:  database  */ 

/*  database  part  */ 

end  extend; 
end  amstate; 


spec  displaywindow 
is 

extend 

rectangle 
dregaddress 
wi  h 

primitive 

op 

dwin:  dregaddr  ret; 
axiom 

xdimret (dwin (a) )  =  [DISPLAYSIZE] succint ( zeroint ( ) ) ; 
ydimret (dwin (a) )  =  [DISPLAYSIZE] succint ( zeroint ()) ; 
origin (dwin (a) )  =  atomofpnt ( fetchdwin (a ,q) ) ; 
end  extend; 
end  displaywindow; 


spec  am 
is 

extend 

memaddress , 
instructiontype , 
typing, 
amstate 
with 

primitive 

op 

y'**************************************** 

*  prog  -  AM  execution 

*  corecursive  -  calls  xeq 
*/ 

prog:  memaddr , state  ^  state; 
hidden 
op 

y'**************************************** 

*  cond  -  implements  conditionals 

*  returns  one  of  two  input  memaddrs 

*  based  on  bool  value 

V 

cond;  val ,  memaddr ,  memaddr  memaddr; 

/**************************************** 

*  xeq  -  corecursive  function 

*  calls  prog 

*  used  for  AM  execution 
*/ 

xeq:  instr , memaddr , state  -*•  state; 
axiom 

prog(a,q)  =  xeq (atoraof instr { fetchm (a ,q) , a , q) ) ; 
cond  (valofbooKtrue  ( )  )  ,al , a2)  =  al; 
cond  (valofbool  ( false  0)  ,al ,  a2)  =  a2; 
xeq (of f st ( i , r ) ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storer ( 

valofmemaddr (offset ( i , atomofmemaddr ( 
fetchr (r ,q) )  ) ) , 
r , 

q 


xeq ( link (r , n) ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storer ( 

valofmemaddr (startmemaddr (lalloc (n,q) )  ) 

r, 

storem( 

fetchr ( r ,q) , 


startmemaddr ( lalloc (n ,q) ,q) 


) 

) 

)  ; 

xeq (unlink (r) ,m,q)  = 
prog  ( 

nextmemaddr (m) , 

If ree ( 

getmemid (atomofmemaddr (f etchr (r ,q) )  )  , 

s torer ( 

fetchm (atomofmemaddr { f etchr (r ,q) ) ,q) 

r , 

q 


)  ; 

xeq (getdwin (d , r) ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storer ( 

fetchdwin (d,q) , 
r , 

q 

) 

)  ; 

xeq (setdwin (r ,d) ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storedwin { 

fetchr (r ,q) , 

d, 

q 

) 

)  ; 

xeq (getmtr (t , r) ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storer ( 

fetchmtr ( t ,q) , 
r , 
q 

) 

)  ; 

xeq ( setmtr (r , t) ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storemtr ( 

fetchr ( r ,q) , 


xeq  (monads  (o  ,  rl)  ,in,q)  = 
prog  ( 

nextmemaddr (m) , 
storer ( 

applymop { 
o, 

fetchr (rl ,q) 

)  , 

rl, 

q 

) 

)  ; 

xeq (monad (o , rl , r2)  ,m,q) 
prog  ( 

nextmemaddr (m) , 
storer ( 

applymop ( 
o , 

fetchr (rl ,q) 

)  , 

r2, 

q 

) 

)  ; 

xeq (monadi (o , V , rl) ,m,q) 
prog  ( 

nextmemaddr (m) , 
storer ( 

applymop (o, v) , 
rl, 

q 

) 

)  ; 

xeq (dyads (o , rl , r2) ,m,q) 
prog  ( 

(nextmemaddr (m) , 
storer ( 

applydop ( 
o, 

fetchr (rl ,q) 
fetchr (r2 ,q) 

)  , 

r2 , 

q 

) 

)  ; 

xeq (dyadsi (o, V, rl) ,ra,q) 
prog  ( 

nextmemaddr (m) , 
storer ( 


applydop { 
o, 

V, 

fetchr (rl ,q) 

)  , 

rl, 

q 

) 

)  ; 

xeq (dyad (o , rl , r2 ,r3) ,m,q)  = 
prog  ( 

nextmemaddr  (:m)  , 
storer ( 

applydop ( 
o, 

fetchr (rl ,q)  , 
fetchr (r2 ,q) 

)  , 

r3, 

q 

) 

)  ; 

xeq  (dyadi  (o  ,  V,  rl ,  r2)  ,in,q)  = 
prog  ( 

nextmemaddr (m) , 
storer ( 

applydop ( 
o, 

V, 

fetchr (rl ,q) 

)  , 

r2 , 

q 

) 

)  ; 

xeq (triads (o , rl , r2 , re) ,m,q) 
prog  ( 

nextmemaddr (m) , 
storer ( 

applytop ( 
o, 

fetchr (rl ,q) , 
fetchr (r2 ,q) , 
fetchr (r3 ,q) 

)  , 

r3, 

q 

) 

)  ; 
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xeq  (triadsi  (0  ,  v,rl,r2)  ,.m,q)  = 
prog  ( 

nextiriemaddr  (m)  , 
storer  ( 

apply top ( 
o, 

V, 

fetchr (rl ,q) , 
fetchr(r2  q) 


xeq (triad (0 , rl , r2 , r3 , r4) ,m,q) 
prog  ( 

nextmemaddr (m) , 
storer ( 

apply top ( 
o, 

fetchr(rl,q) , 
fetchr (r2 ,q)  , 
fetchr (r3 ,q) 

)  , 

r4, 

q 


xeq(triadi(o,v,rl,r2,r3) ,m,q) 
prog  ( 

nextmemaddr (m) , 
storer ( 

applytop ( 
o, 


fetchr(rl,q) , 
fetchr (r2 ,q) 


xeq(quads{o,rl,r2,r3,r4) ,m,q) 
prog  ( 

nextmemaddr (m) , 
storer ( 

applyqop ( 
o, 

f etchr (rl,q) , 
fetchr (r2 ,q)  , 
fetchr (r3 ,q) , 


fetchr (r4 ,q) 


)  , 

r4, 

q 

) 

)  ; 

xeq (quad (o,rl,r2,r3,r4,r5) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storer ( 

applyqop ( 
o , 

fetchr (rl ,q) , 
fetchr (r2 ,q) , 
fetchr (r3,q)  , 
fetchr (r4 ,q) 

)  , 
r5, 

q 

) 

)  ; 

xeq (sexads) o,rl,r2,r3,r4,r5,r6) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storer { 

applysop ( 
o, 

fetchr (rl ,q)  , 
fetchr(r2,q)  , 
fetchr (r3 ,q) , 
fetchr (r4 ,q) , 
fetchr(r5,q) , 
fetchr(r6,q) 

)  , 
r6 , 

q 

) 

)  ; 

xeq(sexad(o,rl,r2,r3,r4,r5,r6,r7) ,m,q) 
prog  ( 

nextmemaddr (m) , 
storer ( 

applysop ( 
o, 

fetchr (rl ,q) , 
fetchr (r2,q) , 
fetchr(r3,q) , 
fetchr (r4 ,q) , 
fetchr(r5,q) , 
fetchr (r6 ,q) 


xeq (octads (o, rl , r2 ,r3 ,r4 , r5 , r6 , r7 , r8) ,m, q) = 
prog  ( 

nextmemaddr (m) , 
storer ( 

applyoop { 
o, 

fetchr (rl ,q) , 
f etchr (r2 ,q) , 
f etchr (r3 ,q) , 
fetchr (r4 ,q) , 
fetchr(r5,q) , 
fetchr (r6 ,q)  , 
fetchr(r7,q) , 
fetchr (r8 ,q) 

)  , 

r8, 

q 

) 

)  ; 

xeq(octad (o, rl ,r2,r3,r4 ,r5,r6 ,r7,r8 ,r9) ,m,q) 
prog  ( 

nextmemaddr (m) , 
storer ( 

applyoop ( 
o, 

fetchr(rl,q) , 
fetchr(r2,q) , 
fetchr(r3,q) , 
fetchr (r4 ,q) , 
fetchr(r5,q) , 
fetchr (r6 ,q) , 
fetchr (r7 ,q) , 
fetchr (r8 ,q) 

)  , 

r9, 

q 

) 

)  ; 

xeq (movi_m(v,ml) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem(v,ml ,q) 

{ ; 

xeq {movi_pcr (v,i) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem ( 


offset (i ,m) , 

q 

) 

)  ; 

xeq  (movi_r  (v,r)  ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storem( 

V, 

offset  ( i  ,in)  , 

q 

) 

) ; 

xeq  (movi_r  ( V,  r)  ,in,q)  = 

prog (nextmemaddr (m) , storer (v,r ,q) ) ; 
xeq (movi_ri (v , r) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem( 

V, 

atomofmemaddr (f etchr (r ,q) ) , 

q 

) 

)  ; 

xeq(movi_rid(v,r,n)  ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storem ( 

V, 

offset ( 
n, 

atomofmemaddr (f etchr {r,q)  ) 

)  , 

q 

) 

)  ; 

xeq (movi_ridn (v,r,il,i2) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem ( 

V, 

offset ( 
i2, 

indir ( 

il, 

atomofmemaddr (f etchr (r,q) ) 


xeq(movi_d(v,r)  ,in,q)  = 

prog (nextmemaddr (m) , stored (v, r ,q)  )  ; 
xeq(mov_m_m(ml,m2)  ,in,q)  = 
prog( 

nextmemaddr (m) , 
storem ( 

fetchm(ml,ql , 
m2 , 

q 

) 

)  ; 

xeq  (mov_m_r  (ml ,  r)  ,m,q)  = 

prog (nextmemaddr (m) , storer ( f etchm (ml ,q) ,r,q)) 
xeq (mov_m_ri (ml , r) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem ( 

fetchm(ml ,q) , 

atomofmemaddr ( f etchr ( r , q) ) 

) 

)  ; 

xeq  (mov_m_rid  (m,  1  ,r  ,n)  ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storem ( 

f etchm (ml, q) , 
offset ( 
n, 

atomofmemaddr ( f etchr ( r ,q) ) 

)  , 

q 

) 

)  ; 

xeq (mov_m_ridn (ml , r , il , 12) ,m,q) = 
prog  ( 

nextmemaddr (m) , 
storem ( 

fetchm(ml ,q) , 
offset ( 
ie, 

indir ( 
il, 

atomofmemaddr ( f etchr (r ,q) ) 

) 

)  , 
a 

) 

)  ; 

xeq (mov_pcr_pcr (il , 12) ,m,q)= 


nextmemaddr (m) , 
storem ( 

fetchmCoffset {il,m)  ,q)  , 
offset (12, m) , 

q 

) 

)  ; 

xeq(mov_pcr_r(i,r)  ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storer ( 

fetchm (of f set (i ,m) ,q) , 
r , 
q 

) 

)  ; 

xeq (mov_pcr_ri ( i , r ) ,m,q)= 
prog) 

nextmemaddr (m) , 
storem ( 

fetchm(offset (i,m) ,q) , 
atomofmemaddr (f etchr (r ,q) ) , 

q 

) 

)  ; 

xeq  (mov_pcr_rid  (il,r,  12)  ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storem ( 

fetchm(offset(ll,m) ,q) , 
offset ( 
i2, 

atomofmemaddr ( f etchr (r ,q) ) 

)  , 

q 

) 

)  ; 

xeq (mov_pcr_rldn (ll,r,n,l2) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem ( 

fetchm (of f set (11 ,m)  ,q)  , 
offset ( 

12, 

Indlr ( 
n, 

atomofmemaddr ( f etchr (r ,q) ) 


xeq  (mov_m_d  (ml ,  r)  ,m,q)  = 

prog (nextmemaddr (m) ,stored ( fetchm(ml ,q) , r ,q) ) 
xeq (mov_r_m ( r , ml ) , m , q ) = 

prog (nextmemaddr (m) ,storem(fetchr (r,q) ,ml,q)) 
xeq (mov_r_pcr (r, i) ,m,q)= 
prog  ( 

nextmemaddr (m)  , 
storem( 

fetchr(r,q) , 
offset(i,m)  , 

q 

) 

)  ; 

xeq  (mov_r_r  (rl ,  r]  )  ,m,q)  = 

prog (nextmemaddr (m) ,storer ( fetchr (rl ,q) ,r2,q) ) ; 
xeq (mov_r_ri (rl , r2) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem( 

fetchr(rl,q) , 

atomofmemaddr ( fetchr ( r2  ,q)  )  , 

q 

) 

)  ; 

xeq  (mov_r_rid  (rl ,  r2  ,n)  ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storem ( 

fetchr(rl,q) , 
offset ( 
n, 

atomofmemaddr ( fetchr ( r2 , q)  ) 

)  , 

q 


xeq (mov_r_ridn (rl , r2 , il , 12) ,m,q) = 
prog  ( 

nextmemaddr (m) , 
storem ( 

fetchr(rl,q) , 
offset ( 

12, 

Indrl ( 
il, 

atomofmemaddr ( fetchr (r2 ,q) ) 


xeq  (mov_r_d  (rl ,  r2)  ,in,q)  = 

prog (nextmemaddr (m) ,stored(fetchr(rl ,q) ,r2,q) ) 
xeq  (mov_ri_m)  r  ,ml)  ,in,q)  = 
prog  ( 

nextmemaddr (m) , 
storem ( 

fetchm(atomofmemaddr (fetchr {r,q) ) ,q) , 
ml , 

q 

) 

)  ; 

xeq  (mov_ri_pcr  (r,i)  ,m,q)  = 
prog  { 

nextmemaddr (m) , 
storem ( 

fetchm(atomofmemaddr(fetchr (r,q) ) ,q) , 
offset ( i ,m) , 

q 

) 

)  ; 

xeq  (mov_ri  ,  r  ( rl ,  rq)^m,q)  = 
prog  ( 

nextmemaddr (m) , 
storer ( 

fetchm(atomofmemaddr ( fetchr ( rl ,q) )  ) , 

r2 , 

q 

) 

)  ; 

xeq  (mov_ri_ri  (rl ,  r2)  ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storem ( 

fetchm (atomofmemaddr ( fetchr (rl ,q) ) ,q) , 
atomofmemaddr ( 
fetchr (r2 ,q) 

)  , 

q 

) 

)  ; 

xeq  (mov_ri_rid)  rl ,  r2  ,n)  ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
storem ( 

fetchm(atomofmem.addr(fetchr  (rl,q)  )  ,q)  , 
offset ( 
n, 

atomofmemaddr ( fetchr ( r2 ,q) ) 


xeq (mov_ri_ridn ( rl , r2 , il , i2)  m,q)  = 
prog  ( 

nextmemaddr (m) , 
storem( 

fetchin{atomofmeniaddr(fetchr(rl,q)  )  ,q) 
of  f  set  ( 
i2, 

indir ( 
il, 

atomofmemaddr ( fetchr (r2 ,q) ) 

) 

)  , 

q 

) 

)  ; 

xeq  {mov_ri_d  (rl ,  r2)  ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
stored ( 

fetchm (atomofmemaddr ( fetchr (rl ,q) )  ) , 
r2, 

q 

) 

)  ; 

xeq (mov_rid_m(r , i ,ml) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem( 

fetchm ( 

offset ( 
i , 

atomofmemaddr (fetchr (r,q) ) 

)  , 

q 

) , 

ml , 

q 

);  ^ 

xeq (mov_rid_pcr) r , il , i2) ,m,q) = 
prog  ( 

nextmemaddr (m)  , 
storem ( 

fetchm ( 

offset ( 
il , 

atomofmemaddr (fetchr (r,q) ) 

)  , 

q 

)  , 


of fset (i2 ,m) , 


xeq (mov_rid_r (rl ,n , r2) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storer { 

f etchm ( 

offset ( 
n, 

atomofmemaddr ( f etchr (rl ,q)  ) 

)  , 

q 

) , 
r2 , 

q 

) 

)  ; 

xeq (mov_rid_ri ( rl , i , r2) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem ( 

f etchm ( 

offset { 

i  / 

atomofmemaddr ( f etchr ( rl , J ) ) 

)  , 
q 

) , 

atomofmemaddr (fetchr(r2,q) )  , 

q 

) 

)  ; 

xeq (mov_rid_rid (rl , il , r2 , 12) ,m,q) = 
prog  ( 

nextmemaddr (m) , 
storem ( 

f etchm ( 

of f set ( 
il , 

atomofmemaddr (f etchr (rl ,q) ) 

)  , 
q 

) , 

offset ( 

12, 

atomofmemaddr (f etchr (r2 ,q) ) 

)  , 

q 

) 

)  ; 

xeq(mov  rid  ridn ( rl , 11 , r2 , 1 , 2 , 13) ,m , q) = 


nextmemaddr (m) , 
storem ( 

f etchm ( 

offset ( 

•  il, 

atomofmemaddr (fetchr (rl,q) ) 

)  , 

a 

)  , 

offset { 
i3, 

indir ( 
i2, 

atomofmemaddr ( fetchr (r 2 ,q) ) 

) 

)  , 

q 

) 

)  ; 

xeq  (mov_rid_d  ( rl  ,n  ,  r2)  ,m,q)  = 
prog  ( 

nextmemaddr (m) , 
stored ( 

f etchm ( 

offset ( 
n, 

atomofmemaddr (fetchr (rl ,q)  ) 

)  , 

q 

)  , 

r2 , 

q 

) 

)  /• 

xeq (mov_ridn_m ( r , n , i ,ml) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem ( 

f etchm ( 

of f set ( 

i, 

indir ( 

n , atomofmemaddr ( fetchr (r ,q)  ) 

) 

)  , 

q 


xeq(mov  ridn  per (r ,n , il , i2) ,m,q) = 


nextmemaddr (m) , 
storem ( 

f etchm ( 

offset ( 
il, 


indir ( 
n, 

atomofmemaddr ( f etchr (r ,q) ) 

) 


offset ( i2m, ) , 


xeq (mov_ridn_r (rl,il,i2,r2) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storer ( 

f etchm ( 

offset ( 
i2 , 


indir ( 

il, 

atomofmemaddr (f etchr (rl ,  q)  ) 


xeq (mov_ridn_r (rl,il,i2,r2) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem ( 

f etchm ( 

offset ( 
i2, 

indir ( 
il, 

atomofmemaddr ( f etchr ( rl ,q) 

) 


atomofmemaddr ( 
fetchr {r2 ,q) 


xeq  (mov_ridn_rid  (rl  ,il,i2,r2,i3)  ,in,q) 
prog  ( 

nextmemaddr (m) , 
storem ( 

f etchm ( 

of f set ( 

12, 

indir ( 

il, 

atomofmemaddr ( f etchr ( rl , q)  ) 

) 

)  , 

q 

) , 

offset ( 

13, 

atomofmemaddr ( f etchr (r2 ,q) ) 

)  , 

q 

) 

)  ; 

xeq (mov_ridn_ridn (rl,il,i2,r,i3,i4) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem ( 

f etchm ( 

of f set ( 

12, 

indir ( 

11, 

atomofmemaddr ( f etchr (rl ,q)  ) 

) 

)  , 

q 

) , 

offset ( 

14, 

Indir ( 

13, 

atomofmemaddr (f etchr (r2 ,q) ) 

) 

)  , 

q 

) 

)  ; 

xeq (mov_rldn_d (rl ,ll,lr,r2) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
stored ( 

fetchm ( 


offset ( 
i2, 

indir ( 

11/ 

atomofmeinaddr  ( fetchr  (rl  ,q)  ) 

) 

)  , 

q 

) , 

r2 , 

q 

) 

)  ; 

xeq (mov_d_m (r ,ml) ,m,q)= 

prog (nextmemaddr (m) , storem (fetchd (r ,q) ,ml,q) ) ; 
xeq ( mo v_d_pcr ( r , i ) , m , q ) = 
prog  C 

nextmemaddr (m) , 
storem ( 

fetchd (r ,q)  , 
offset (i ,m) , 

q 

) 

)  ; 

xeq (mov_d_r (rl , r2) ,m,q)= 

prog (nextmemaddr (m) ,storer(fetchd(rl ,q) ,r2,q) ) 
xeq (mov_d_ri (rl , r] ) ,m,q) = 
prog  ( 

nextmemaddr (m) , 
storem ( 

fetchd (rl ,q) , 

atomofmemaddr (fetchr (r2 ,q) ) , 

q 

) 

)  ; 

xeq (mov_d_rid (rl , r2 ,n) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
stroem( 

fetchd (rl ,q) , 
offset ( 
n, 

atomofmemaddr ( fetchr ( r2 , q) ) 


xeq (mov_d_ridn ( rl , r2 , 11 , 12) ,m,q) = 
prog  ( 

nextmemaddr (m) , 
storem ( 

fetchd (rl ,q) , 


offset ( 
i2, 

indir ( 
il, 

atomofmemaddr  {.f  etchr  (r2  ,q)  ) 

) 

)  , 

q 

) 

)  ; 

xeq (mov_d_d (rl , r2) ,m,q)= 

prog (nextmemaddr (m) , stored ( f etchd (rl,q) ,r2,q)  )  ; 
xeq (push_i (v,s)  ,m,q)  = 

prog (nextmemaddr (m) ,pushstk ( v, s ,q) ) ; 
xeq (push_pcr ( i , s) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
pushstk ( 

fetchm(offset (i,m)  ,q)  , 

s, 

q 

) 

)  ; 

xeq (push_r (r , s) ,m,q)= 

prog (nextmemaddr (m) , pushstk ( f etchr (r ,q) s,q) ) ; 
xeq (push_ri (r ,s) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
pushstk ( 

fetchm (atomofmemaddr ( f etchr (r ,q) ) ,q) , 
s, 

q 

) 

)  : 

xeq (push_rid (r ,n ,s ) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
pushstk ( 
fetchm ( 

offset ( 
n, 

atom.ofmemaddr  (f etchr  (r,q)  ) 

)  , 

q 

)  ,  ' 
s, 

q 

) 

)  ; 

xeq (push_ridn (r , il , i2 ,s) ,m,q)= 
prog  ( 

nextmemaddr (m) , 


pushstk { 
fetchm ( 

offset { 

12, 

indir ( 

11, 

atomofmemaddr (fetchr (r ,q) ) 


s, 

q 

) 

)  ; 

xeq (push_d (r , s) ,m,q)= 

prog (nextmemaddr (m) , pushstk (fetchd (r,q) ,s,q) ) 
xeq(pop_x(s) ,m,q)= 

prog (nextmemaddr (m) ,popstk (s ,q) ) ; 
xeq ( pop_m ( s , ml ) , m , q ) = 
prog  ( 

nextmemaddr (m) , 
popstk ( 
s, 

storem ( 

topstk (s ,q) , 
ml , 

q 

) 

) 

)  ; 

xeq (pop_pcr (s , 1) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
popstk ( 
s , 

storem { 

topstk (p,q) , 
offset ( 1 ,m) , 

q 

) 

) 

)  ; 

xeq ( pop_r ( s , r )  , m , q )  = 
prog  ( 

nextmemaddr (m) , 
popstk ( 
s, 

storer ( 

topstk (s ,q) , 


prog  ( 

nextmemaddr (m) , 
popstk ( 
s, 

storem( 

topstk (s,q)  , 

atomofmemaddr ( f etchr (r ,q) ) , 

q 

) 

) 

)  ; 

xeq (pop_rid ( s , r ,n)  ,m,q)  = 
prog  ( 

nextmemaddr  (m)  , 
popstk ( 
s, 

storem( 

topstk(s,q) , 
of f set ( 
n, 

atomofmemaddr (fetchr (r ,q) ) 

)  , 

q 

) 

) 

)  ; 

xeq (pop_ridn (s , r , il , i2) ,m,q)= 
prog  { 

nextmemaddr (m) , 
popstk ( 
s, 

storem( 

topstk (s,q)  , 
offset ( 

12, 

indir ( 
il, 

atomofmemaddr ( fetchr (r ,q) ) 

) 

)  , 
q 

) 

) 

)  ; 

xeq (pop_d (s , r) ,m,q)= 
prog( 

nextmemaddr (m) , 
popstk { 


stored ( 

topstk (s ,q) , 

r, 

q 

) 

) 

)  ; 

xeq  (nop,in,q)  =  prog(nextmemaddr(in),q); 
xeq (stop,m,q)  =  prog(m,q)  =  q; 
xeqOmp(ml)  ,m,q)  =  prog(ml,q); 

xeq ( jmp_i (ml) ,m,q)  =  prog (atomofmemaddr (fetchm(ml ,q) ) ,q) 
xeq ( jmp_r (r) ,m,q)  =  prog(atomofmemaddr(fetchr(r,q)),q); 
xeq (bra (n) ,m, q)  =  prog (of f set (n , nextmemaddr (m) ) , q) ; 
xeq (bra_r , r ,m,q)  =  prog (of f set ( atomof int ( f etchr ( r , q) ) , 

nextmemaddr (m) ) ,q) ; 
xeq (if (o , rl , r2 ,ml) ,m,q)= 
prog  ( 
cond  ( 

applyrop ( 
o, 

fetchr (rl ,q) , 
fetchr (r2,q) , 

)  , 

ml , 

nextmemaddr (m) 

)  , 

q 

)  ; 

xeq(ifi (o,r,v,ml) ,m,q)= 
prog  ( 
cond  ( 

applyrop ( 
o, 

fetchr (r ,q) , 

V 

)  , 

ml , 

nextmemaddr (m) 

)  , 

q 

)  ; 

xeq ( (if te (o , rl , r2 ,ml ,m2) ,m,q)= 
prog  ( 

cond  ( 

applyrop ( 
o, 

fetchr(rl,q) , 
fetchr(r2,g) 


xeq (iftei (o , r , V ,ml ,ra2) ,m,q)= 
prog  ( 

cond  ( 

applyrop ( 

o, 

fetchr (r ,q) , 

V 

)  , 
ml , 
m2 

)  , 

q 

)  ; 

xeq ( if_pcr) o , rl , r2 ,n) ,m,q)= 
prog  ( 
cond  ( 

applyrop ( 
o, 

fetchr (rl ,q) 
fetchr (r2 ,q) 

)  , 

off set (n ,nextmemaddr (m) ) , 
nextmemaddr (m) 

)  , 
q 

)  ; 

xeq(ifi_pcr (o,r,v,n) ,m,q)= 
prog  ( 
cond  ( 

applyrop ( 
o, 

fetchr(r,q) , 

V 

)  , 

of f set (n , nextmemaddr (m) ) , 
nrxtmemaddr (m) 

)  , 

q 

)  ; 

xeq ( if te_pcr (o ,rl ,r2 ,il,i2) ,m,q)= 
prog  ( 
cond  ( 

applyrop ( 
o , 

fetchr(rl,q) , 
fetchr {r2,q) 

)  , 

offset (il, nextmemaddr (m) ) 


of f set (i2 ,nextmemaddr (m) ) 

)  , 

q 

)  ; 

xeq (iftei_pcr (o ,r , V, il , i2) ,m,q) = 
prog  ( 
cond  ( 

applyrop ( 
o, 

fetchr (r ,q) , 

V 

)  , 

offset  (il,nextmeinaddr  (m)  )  , 
of f set (12 ,nextmemaddr (m) ) 

)  , 

q 

)  ; 

xeq ( test (o , rl ,ml) ,m,q)= 
prog  ( 
cond  ( 

applybop (o , fetchr (rl ,q)  )  , 
ml , 

nextmemaddr (m) 

)  , 

q 

)  ; 

xeq ( testm (o ,m2 ,ml ) ,m,q)= 
prog  ( 
cond  ( 

applybop. (o , fetchm (m2  ,q)  )  , 
ml , 

nextmemaddr (m) 

)  , 

q 

)  ; 

xeq ( teste (o , rl ,ml ,m2) ,m,q)= 

prog (cond (applybop (o , fetch (rl ,q) ) ,ml,m2) ,q) ; 
xeq ( testme (o ,m3 ,ml ,m2) ,m,q)= 

prog (cond (applybop (o , fetchm(m3 ,q) ) ,ml,m2) ,q) 
xeq ( test_pcr (o ,rl ,n) ,m,q)= 
prog( 
cond( 

applybop (o , f etchr (rl ,q) )  , 
offset (n, nextmemaddr (m) ) , 
nextmemaddr (m) ; 

)  , 


applybop (o , fetchm{m2 ,q) ) , 
of  f  set  (n  ,nextinemaddr  (ml)  , 
nextmemaddr (m) 


xeq ( teste_pcr (o , rl ,il,i2)m,q)= 
prog  ( 
cond  ( 

applybop (o ,fetchr Crl ,q) ) , 
of f set (il ,nextmemaddr (m) ) , 
offset (12 ,nextmemaddr (m) ) 

)  , 
q 

)  ; 

xeq ( testme_pcr (o,m2,il,i2) ,m,q)= 
prog  ( 

cond  { 

applybop (o , fetchm{m3 ,q) )  , 
of fset (il ,nextmemaddr (m) ) , 
of f set ( i2 , nextmemaddr (m) ) 


xeq ( j sr (ml , s) ,m,q)= 

prog (ml /pushstk (valofmemaddr (nextmemaddr Cm) ) ,s,q) ) ; 
xeq ( j sr_i (ml , s) ,m,q)= 
prog  ( 

atomofmemaddr (fetchm(ml ,q) ) , 

pushstk (valofmemaddr (nextmemaddr (m) ) , s ,q) 

)  ; 

xeq( jsr_r(r,s) ,m,q)= 
prog  ( 

atomofmemaddr (fetchr(r,q)  ) , 

pushstk (valofmemaddr (nextmemaddr (m) ) , s ,q) 

)  ; 

xeq(bsr(n,s)  ,m,q)  = 
prog  ( 

offset (n,nextmemaddr(m) ) , 

pushstk (valofmemaddr (nextmemaddr (m) ) ,s,q) 

)  ; 

xeq (bsr_r (r, s) ,m,q)= 
prog  ( 

offset ( 

atomof int (f etchr (r ,q) ) , 
nextmemaddr (m) 

)  , 

pushstk (valofmemaddr (nextmemaddr (m) ) ,s,q) 

)  ; 

xeq(rts  s,m,q)= 

prog (atmoofmemaddr (topstk ( s  ,q) )  ,popstk (s ,q) )  ; 
xeq (open (s) ,m,q) = 


-  *  fc 

•  -  •  ^ 

J' 


c 


nextmemaddr (ml , 
openf ile ( 

atomof str ,char ( topstk ( s , popstk { s , popstk 
(s,popstk(s,q) )  ) )  ) , 

atomof file (topstk ( s , popstk ( s , popstk ( s ,q) )  )  ) 
atomof int (topstk (s , popstk (s ,q) )  ) , 
atomof int (topstk (s ,q)  )  , 
popstk (s ,q) 

) 

)  ; 

xeq(close(s) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
closef ile ( 

atomoff ile (topstk ( s ,q) ) , 
popstk (s ,q) 

) 

)  ; 

xeq(read(s) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
storem( 

infile ( 

atomof file (topstk ( s ,popstk ( s ,q) )  ) , 
popstk (s ,q) 

)  , 

atomofmemaddr (topstk (s ,q) ) , 
popstk (s ,q) 

) 

)  ; 

xeq(write(s) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
outf ile ( 
f etchm ( 

atomofmemaddr ( topstk ( s , popstk ( s , q ) )  ) , 
popstk (s ,q) 

)  , 

atomof file (topstk (s ,q)  )  , 
popstk (s ,q) 

) 

)  ; 

xeq (write_i  ( V ,qu)  ,m,q) =  /*  database  part  */ 

prog (nextmemaddr (m) ,write ( v,qu ,q) ) ; 
xeq(write_m(ml,qu) ,m,q)= 

prog (nextmemaddr (m) ,write (f etchm (ml ,q) ,qu,q) ) ; 
xeq (write_r (r ,qu) ,ra,q)= 

prog (nextmemaddr (m) , write ( fetchr (r ,q) ,qu,q) ) ; 
xeq (delete_x (qu) ,m,q)= 

prog (nextmemaddr (m) , delete (qu,q) ) ; 


xeq (delete_m(qu,ml) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
delete ( 

qu, 

storem ( 

read(qu,q) , 
ml , 

q 

) 

)  ;  ) 

xeq (delete_r (qu,r) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
delete ( 


qu, 

storer ( 

read(qu,q) , 
r, 

q 

) 

) 

)  ; 

xeq(open(s) ,m,q)= 
prog( 

nextmemaddr (m) , 
open  ( 

atomofstr.char (vl) , 
atomofdb {v2) 

) 

)  ; 

xeq(close(s) ,m,q)= 
prog  ( 

nextmemaddr (m) , 
close ( 

atomofstr.char (vl) , 
atomofdb (v2) 


)  ; 

end  extend; 
end  am: 


/*  database  part  */ 


APPENDIX  C 


A  SIMPLE  ASSEMBLER  FOR  AM 


1.  Introduction 

This  document  is  adapted  from  Yurchak  [Ref.  2] ,  Appendix 
C,  and  constitutes  the  reference  manual  for  both  version  2.0- 
ZlOO,  developed  by  Hunter  [Ref.  3],  and  the  latest  modification 
towards  version  3.0.  It  provides  a  comprehensive  description 
of  the  syntax  and  semantics  of  the  assembler  as  well  as  a 
description  of  the  salient  features  of  the  AM  machine  and  a 
definition  of  the  opcodes  executed  by  AM. 

AMASM  is  an  as.sembler  which  generates  a  relocatable  load 
module  for  the  abstract  machine  interpreter  AM.  It  is  to  the 
extent  possible  written  in  portable  C.  The  parser  and  scanner 
were  produced  using  the  Unix  YACC  and  LEX  utilities.  The 
output  from  these  utilities  require  several  patches  to  allow 
compilation  on  the  ZlOO  using  Lattice  'C.'  Readers  desiring 
to  port  the  code  to  other  machines  may  have  to  make  slight 
changes  to  "defines."  In  this  implementation,  longs  are 
assumed  to  occupy  32  bits,  both  int  and  short  -  16  bits,  and 
char  -  8  unsigned  bits.  NOte:  if  the  int  size  changes,  then 
the  infile  and  outfile  fiinctions  in  amstate.c  must  be  changed. 

The  input  syntax  of  AMASM  is  similar  to  that  of  other 
assemblers.  It  supports  symbolic  addresses  and  constants  and 
a  typical  set  of  directives,  but  has  no  macro  capabilities. 

The  assembler  accepts  an  ASCII  source  file  created  on  a  con¬ 
ventional  text  editor  and  produces  an  output  file  containing 
relocation  information  and  AM  opcodes.  Invoking  AM  causes  the 
output  file  "a. am"  to  be  loaded  and  executed. 


2.  Differences  from  Version  1.0 

Since  it  was  our  intention  to  primarily  specify  and  des¬ 
cribe  the  abstraction  of  a  database  resource,  the  assembler 
part  for  AM  was  considered  to  be  of  less  importance  for  this 
thesis.  Due  to  the  limited  time  the  adaption  of  AMASM  to  the 
database  requirements  is  still  incomplete,  only  some  examples 
are  given  which  indicate  a  way  of  how  to  integrate  this  latest 
resource.  Thus,  for  instance,  although  the  read/write  com¬ 
mands  for  the  queue  were  developed,  the  method  of  actually 
retrieving  objects  from  the  queue  has  not  yet  been  defined. 

The  same  is  true  for  the  database  itself,  where  the  only 
commands  described  are  those  for  opening  and  closing  the 


database,  while  the  other  operations  were  left  undefined  for 
the  above  reasons.  So,  in  fact,  AM  (version  3.0)  represents 
only  a  partial  extension  of  AM  (version  2.0-Z100). 


3.  Usage 

AMASM  is  invoked  with  the  following  command  line  syntax: 

amasm  [-t]  [-x]  [-s]  [-1]  file  ... 

AMASM  produces  a  single  load  module  "a. am,"  which  forms  the 
input  to  the  AM  loader.  The  optional  "-t"  switch  sends  a  de¬ 
bugging  trace  to  "stdout,"  the  "-x"  switch  provides  an  extended 
version  of  the  trace,  and  the  "-s"  switch  provides  trace  of 
the  recognized  scanner  tokens.  The  optional  "-1"  switch  gener¬ 
ates  the  listing  and  cross-reference  file  "a.x.”  Appended  to 
this  file  is  a  hex  dump  of  "a. am." 


4 .  Lexical  Conventions 

Assembler  tokens  include  identifiers  (alternatively, 

"symbols"  or  "names"),  literal  constants,  operators  and  delimiters 

4.1.  Identifiers 

Legal  identifiers  are  described  by  the  following  regular 
expression : 

[A-Za-z] [A-Za-zO-9]* 

Identifiers  consist  of  a  letter  or  underline  followed  by  a 

string  of  zero  or  more  letters,  decimal  digits  and  underlines. 
Upper  and  lower  case  are  distinct.  Identifiers  may  represent 
symbolic  constants,  instruction  mnemonics,  labels,  addresses 
and  type  names. 

4.2.  Operators 

The  following  are  considered  to  be  operators: 

+  -*/%&  I 

The  meaning  of  the  above  symbols  varies  with  context. 

4.3.  Literal  Constants 

Decimal  and  hexadecimal  constants  are  described  by  the 
following  regular  expressions  respectively: 

[-+] [0-91+1  [0-9]+ 

$  [0-9A-Fa-f]+ 


Decimal  constants  consist  of  an  optional  sign  followed  immedi¬ 
ately  by  one  or  more  decimal  digits.  Hexadecimal  constants 
consist  of  the  character  followed  immediately  by  a  string 

of  one  or  more  decimal  digits  and  upper  or  lower  case  letters 
"A"through  "F. "  Numeric  constants  may  represent  addresses, 
integer  and  natural  numbers,  boolean  and  character  values. 

II  II 

Character  constants  consist  of  a  single  quote  '  ,  followed 
either  by  an  ASCII  character,  that  is  not  a  carriage  return/ 
linefeed  or  a  numeric  constant,  followed  by  a  closing  single 
quote , 

String  constants  consist  of  a  string  of  zero  or  more  ASCII 
characters  (except  carriage  return/linefeed)  enclosed  in  double 
quotes . 

4.4.  Blanks 

Blanks  and  tabs  are  ignored  by  the  assembler  except  where 
required  to  separate  adjacent  constants  or  identifiers. 

4 . 5.  Comments 

The  character  produces  a  comment.  The  assembler  ignores 

all  further  characters  on  the  line  up  to  the  terminating 
carriage  return/li.nef eed . 

4.6.  Delimiters 

All  other  characters  found  in  the  input  stream  are  treated 
as  delimiters. 


5.  Statements 

A  source  program  is  composed  of  a  sequence  of  statements, 
one  statement  per  line.  There  are  1  kinds  of  statements; 
directives,  instructions  and  null. 

Instructions  and  null  statements  may  be  preceded  by  a  label. 
Directives  may  (in  some  cases,  must)  be  preceded  by  an 
identifier. 

5.1.  Labels  &  Identifiers 

A  label  consists  of  an  identifier  followed  by  a  colon 
When  the  assembler  encounters  a  label,  the  effect  is  to  assign 
the  current  value  of  the  location  counter  to  the  name. 


An  identifier  preceding  a  directive  is  assigned  a  value 
whose  type  depends  upon  the  directive.  For  instance,  the  equate 


directive  assigns  a  typed  value  to  an  identifier,  while  the 
define  storage  directive  assigns  the  current  value  of  the 
location  counter. 

Neither  labels  nor  identifiers  may  be  redefined  within 
a  single  source  file. 

5.2.  Null  Statements 

A  null  statement  is  an  empty  statement.  Although  ignored 
the  assembler,  null  statements  may  be  preceded  by  a  label. 

5.3.  Directive  Statements 

A  directive  is  a  command  to  the  assembler  to  perform  some 
sort  of  operation  which  does  not  involve  emitting  an  executable 
instruction.  Typical  directives  (also  known  as  "pseudo  ops" 
or  "pseudo  instructions")  allocate  storage  for  variabJes,  make 
names  within  the  current  module  visible  to  other  modules  and 
set  the  location  counter.  Directives  also  produce  instructions 
for  the  AM  linker  and  loader. 

Directives  consist  of  a  keyword  followed  by  zero  or  more 
arguments,  depending  upon  the  context.  Directives  and  their 
syntax  are  described  in  more  detail  in  Section  12. 

5.4.  Instruction  Statements 

Instruction  statements  produce  the  code  which  is  ultimately 
executed  by  AM.  An  instruction  may  be  preceded  by  a  label, 
and  consists  of  a  keyword  followed  by  zero  or  more  arguments, 
depending  upon  context. 

The  AM  instruction  set  and  its  syntax  will  be  described  in 
detail  in  Section  14. 


6.  The  Machine 

Because  AM  differs  from  conventional  machines  in  a  number 
of  important  ways,  some  discussion  is  necessary  before  intro¬ 
ducing  the  instruction  set.  Outwardly  similar  to  a  number  of 
well-known  examples,  AM  instructions  form  an  unconventional 
set  of  primitive  operations  which  implement  a  formally  speci¬ 
fied  semantics.  The  reasons  for  this  are  described  below. 

AM  uses  a  tagged  architecture.  Thus,  each  data  element 
contains,  within  it,  information  which  uniquely  identifies  a 
finite  set  of  legal  operations  which  may  be  performed  upon  it, 
as  well  as  a  range  of  legal  values  it  may  take  on.  This  set 
of  operations  and  values  is  known  formally  as  a  data  type. 

AM  supports  a  number  of  data  types.  An  element  of  a  particular 
data  type  will  be  referred  to  throughout  the  rest  of  this  manual 
as  an  atom. 


AM  physical  resources  are  partitioned  into  segments.  There 
are  several  types  of  segments,  and  these  together  form  a  con¬ 
ventional  overall  model  of  the  familiar  stored  program  computer. 
There  are  memory  segments  (primary  storage) ,  register  seg¬ 
ments  (high-speed  memory) ,  display  register  segments  (bit¬ 
mapped  display  memory),  stacks,  a  queue,  a  monitor  (display 
terminal  attributes)  and  file  segments  (secondary  storage) . 
Segments  are  further  partitioned  into  discrete,  addressable 
elements  (alternatively,  "cells")  which  will  contain  atoms 
during  the  execution  of  a  program.  These  elements  will  be 
referred  to  repeatedly  as  typed  values.  The  reason  for  the 
distinction  between  atoms  and  values  will  become  more  clear 
shortly . 

AM  is  the  finite  implementation  of  a  formal  specification. 

As  such,  data  elements  and  the  operations  which  can  be  applied 
to  them  must  reflect  a  mathematical  consistency  not  required 
by  conventional  architectures.  Since  all  operations  which 
affect  the  state  of  the  machine  must  be  able  to  "communicate" 
with  each  other  during  the  execution  of  a  AM  program,  they  must 
do  so  using  a  common  object.  This  object  is  a  value.  The 
memory,  registers,  display  registers,  stack,  queue,  and  files 
all  hold  values.  Store,  fetch,  execute,  read,  write--any 
operations  which  change  the  state  of  the  machine--all  operate 
on  values  ( i . e. , storage  cells).  All  other  operations,  such  as 
"add,"  "multiply';  "and,"  and  "or,"  work  on  atoms.  Atomic 
operations  in  AM  correspond  to  those  which  take  place  in  the 
temporary  registers  of  the  arithmetic  and.  logic  unit  a  con¬ 
ventional  processor. 

6.1  Configuration 

A  unique  feature  of  AM  is  the  ease  with  which  it  is  possible 
to  reconfigure  the  machine  by  partitioning  the  physical  resources 
in  different  ways.  A  typical  configuration  would  be  something 
like  this: 

2  memory  segments 

1  register  segment  (with  a  useful  number  of  registers) 

1  display  register  segment  (with  one  or  two  registers) 

1  stack 

1  queue 

1  monitor  (only  one  is  permitted) 

1  database  (one  or  more  are  possible) 

16  files 

The  configuration  chosen  should  provide  a  good  indication  of 
the  types  of  programs  AM  is  intended  to  execute. 

Note  that,  In  conventional  machines,  stacks  are  implemented 
in  primary  storage.  This  constitutes  an  overloading  of  data 
structures  which  obscures  the  intent  of  the  user  of  these 
structures.  It  also  creates  a  semantic  nightmare  for  the 


specification  writer.  In  AM,  stacks  and  queue  take  their 
rightful  places  as  separate  entities  with  easy  to  understand 
properties . 

In  addition  to  the  resources  listed  above,  AM  has  a  con¬ 
ventional  program  counter. 

6.1.1.  Memory 

AM  memory  is  partitioned  into  segments  which  may  be  of  un¬ 
equal  but  fixed  length.  A  program  and  its  data  will  reside 
in  memory  segments.  It  is  not  necessary  that  code  and  data 
share  the  same  segment,  nor  is  it  required  that  code  and  data 
be  contiguous.  The  loader  will  determine  from  the  origin 
directive  where  to  load  code  and  data  values. 

The  AM  heap  is  implemented  as  a  set  of  operations  which 
allocate  and  deallocate  memory  segments. 

AM  has  a  rich  set  of  addressing  modes  which  interact  with 
a  powerful  move  instruction  which  allows  the  programmer  to 
move  a  value  from  "anywhere  to  anywhere." 

61.2.  Registers 

AM  registers  form  the  high-speed  storage  into  v/hich  oper¬ 
ands  are  placed. 

All  atomic  operations,  such  as  add,  divide  and  poffst, 
require  operands  to  be  in  registers.  Form  operations  are  an 
exception.  Their  operands  may  be  in  either  a  register  or  a 
display  register. 

6.1,3.  Display  Registers 

The  form  is  the  atomic  data  type  that  represents  an  image. 
Like  any  other  atomic  data  type,  it  may  be  placed  in  any  memory, 
register,  stack  or  file  cell.  A  form  can  not  be  "viewed"  by 
the  monitor  unless  it  is  in  a  display  register. 

Display  registers  may  only  contain  form  values.  Each  dis¬ 
play  register  has  its  own  window  which  is  fixed  in  size  but 
with  a  variable  origin.  The  display  window  determines  what  part 
of  the  form  is  "viewed"  by  the  monitor. 

In  general,  display  registers  may  be  partitioned  into  multi¬ 
ple  segments.  However,  the  hardware  on  most  machines  will  only 
support  one  segment  of  one  or  two  registers.  A  segment  of 
two  display  registers  is  equivalent  to  the  idea  of  a  "front" 
and  "back"  plane. 


6.1.4.  Monitor 


The  monitor  represents  a  set  of  terminal  attributes  which 
are  part  of  the  "state  of  the  machine."  The  attributes: 
vertical  and  horizontal  number  of  pixels,  vertical  and  hori¬ 
zontal  screen  dimensions,  intensity  capability  and  color  planes 
are  fixed  for  any  terminal.  The  background  color  and  display 
register  selection  attributes  are  programmable. 

6.1.5.  Stack 

The  AM  stack  is  conventional  in  every  respect  except  that 
it  is  impossible  to  access  any  value  except  the  top.  Thus, 
frames  are  implemented  on  the  heap,  not  the  stack. 

AM  has  a  typical  set  of  push  and  pop  instructions  for 
operating  on  stacks. 

6.1.6.  Files 

Input/output  is  implemented  rather  arbitrarily  along  the 
lines  of  system  calls  to  an  operating  system  and  should  not  be 
considered  part  of  AM  itself. 

Instructions  are  provided  to  open,  close,  read  to  and  write 
from  a  file. 

6 . 1,  7  .  Queue 

Primarily,  the  queue  acts  as  a  buffer  for  'objects'  being 
retrieved  from  the  database  during  a  select  operation.  It  is 
implemented  in  the  same  way  as  the  stack  to  prevent  the  access¬ 
ing  of  any  value  except  the  one  residing  in  the  front  position. 
This  method  ensures  that  the  order  of  the  values  defining  an 
object  will  be  kept. 

A  set  of  write  and  read  instructions  is  provided  for 
operating  on  the  queue. 

6-1.8.  Database 

The  database  consists  of  two  major  parts:-  the  data  repre¬ 
senting  the  information  and  a  set  of  commands  to  perform  the 
defined  operations  on  it.  These  commands  can  only  be  applied 
to  data  that  have  explicitly  been  specified  as  a  database  and 
meet  its  structural  requirements.  In  principle,  the  data  need 
to  be  arranged  as  ordered  pairs  of  lists.  For  database  opera¬ 
tions  all  resources  of  AM  may  be  used,  with  exception  of  the 
display  registers  and  the  monitor. 


Instructions  are  provided  to  open  and  close  the  database. 


7 . 0  Atoms 


An  atom  is  a  component  of  a  data  type.  The  assembler 
recognizes  the  following  type  of  atoms: 

file  address 

pidlist 

pidsetlist 

vallist 

valsetlist 

proplist 

propsetlist 

pvallist 

pvalsetlist 

ob j list 

classlist 

dblist 

qaddress 

As  operands  to  instruction  mnemonics,  these  atoms  form  the 
familiar  set  of  literal  and  symbolic  constants  found  in  typi¬ 
cal  assembly  language  programs. 

With  certain  exceptions,  atoms  may  appear  in  the  form  of 
literal  constants: 

100 

$d0fl 

'  a ' 

"this  is  a  s.tring  atom" 

They  may  also  appear  as  symbols  which  take  on  the  value  of  the 
atom  in  some  other  part  of  the  source  program.  With  few  excep 
tions,  anywhere  a  literal  constant  may  be  used,  a  symbolic 
constant  of  the  appropriate  type  may  also  be  used. 

The  assembler  distinguishes  between  types  of  atoms  using 
syntax  and  context.  The  syntax  is  described  below. 

7.1.  Boolean 

A  boolean  atom  has  only  two  values,  true  and  false.  These 
values  are  represented  to  the  assembler  by  the  decimal  or 
hexadecimal  constants  for  1  and  0,  respectively. 

0 

], 

$1 

$0 

are  legal  boolean  atoms. 

7.2.  Natural 

This  type  represents  as  the  name  implies,  the  natural  (un¬ 
signed)  numbers.  Legal  value.s  range  from  zero  to  positive 


infinity.  Natural  numbers  are  represented  to  the  assembler  as 
decimal  or  hexadecimal  constants  whose  values  are  greater  than 
or  equal  to  zero. 

0 

$2f5 

240 

are  legal  natural  atoms. 

7.3.  Integer 

Integers  range  from  negative  to  positive  infinity,  and  are 
specified  as  hexadecimal  or  signed  or  unsigned  decimal  constants 

-250 

0 

$ed67f 

+10 

are  legal  integer  atoms. 

7.4.  Character 

Character  atoms  may  take  values  defined  by  the  ASCII 
character  set.  They  are  represented  to  the  assembler  as  literal 
character  constants. 


are  legal  character  atoms. 

7.5.  String 

String  atoms  are  composed  of  zero  or  more  concatenated  ACIII 
characters.  They  are  specified  as  literal  strings. 

"this  is  a  legal  string  atom" 

fl  II 

are  both  legal  string  atoms. 

7.6.  Intensity 

An  intensity  atom  ranges  from  0  to  199  decimal.  It  is 
represented  as  a  unsigned  decimal  or  hexadecimal  constant  pre¬ 
ceded  with  the  character  represents  the  null  intensity 

which  is  used  to  construct  the  null  color. 

&0 

&89 

&199 

are  legal  intensity  atoms. 


7.7.  Color 


A  color  atom  is  a  composite  of  a  red,  green  and  blue  inten 
sity.  It  is  represented  as  an  ordered  triple  of  unsigned 
decimal  or  hexadecimal  constants  separated  by  commas 
enclosed  within  parenthese  and  preceded  with  The 

nullcolor  provides  the  concept  of  background  and  transparency. 
It  is  represented  as  the  enclosed  within  parentheses  and 
preceded  with 

&(0,0,0) 

&(70, 0,190) 

&@ 

are  legal  color  atoms. 

7.8.  Point 

Points  are  composed  of  integer  pairs.  The  x  and  y  coor¬ 
dinates  correspond  to  the  first  and  second  integers  respec¬ 
tively.  Increasing  integer  values  represents  positions 
shifted  right  and  up.  A  point  is  represented  as  an  ordered 
pair  of  decimal  or  hexadecimal  constants  separated  by  a 
comma  ","and  enclosed  within  parentheses 

(0,0) 

(4,1047) 

(-8,25) 

(-50677,-293399) 
are  legal  point  atoms. 

7.9.  Rectangles 

Rectangles  are  composed  of  a  pair  of  points  which  repre¬ 
sent  the  opposing  corners.  A  rectangle  is  represented  as  an 
unordered  pair  of  points  separated  by  a  colon  and  enclosed 

within  square  brackets 

[  (0,0)  ;  (0,0) ] 

[ (0,0)  :  (50,45) ] 

[  (50,45)  ;  (0,0) ] 

[  (-20,-20000)  :  (30,59) ] 

are  legal  rectangle • atoms , 

7.10.  Form 

A  form  atom  is  a  composite  structure.  It  has  a  two  dimen¬ 
sional  size  and  a  color  map  which  is  an  array  of  colors  with 
each  color  corresponding  to  a  point  in  its  area.  The  form 
atom  has  no  literal  constant  representation.  it  is  created 
using  the  operator,  newfrm,  and  modified  using  other  operators 


A  font  atom  is  an  array  of  forms.  The  font  atom  has  no 
literal  constant  representation.  It  is  constructed  from  the 
operator,  newfnt,  and  modified  using  other  operators. 

7.12.  Ptblt 

A  ptblt  atom  is  a  composite  of  three  rectangles  and  a 
natural  which  represents  a  copy  rule.  The  ptblt  atom  has  no 
literal  constant  representation.  It  is  constructed  from  the 
operator,  newblt,  and  is  modified  using  other  operators. 

7.13.  Memory  Address 

Memory  address  atoms  consist  of  two  components:  a  segment 
address, and  an  element  address.  Memory  addresses  are  repre¬ 
sented  as  an  ordered  pair  of  unsigned  decimal  or  hexadecimal 
constants,  separated  by  a  colon  and  enclosed  within 

parentheses 

(0:100) 

represents  memory  segment  0,  element  100. 

(2:$10) 

represents  segment  2,  element  16. 

Segment  and  element  addresses  start  at  0.  The  number  and 
size  of  available  memory  segments  depends  upon  the  current 
configuration  of  AM. 

Labels  are  considered  memory  address  atoms,  as  are  names 
which  appear  to  the  left  of  the  define  storage  and  define 
constant  directives. 

7.14.  Register  Address 

Register  address  atoms  have  a  syntax  identical  to  that  of 
memory  addresses  except  that  a  lower  case  "r"  is  prepended  to 
the  address. 

r(0:3) 

refers  to  register  segment  0,  register  3. 

Segment  and  element  addresses  start,  as  with  memory  addresse 
at  0.  The  number  of  register  segments,  and  the  number  of 
registers  within  each  segment,  varies  as  determined  by  the 
current  AM  configuration. 

7.15.  Display  Register  Address 

Display  register  address  atoms  have  a  syntax  identical  to 
that  of  register  addresses  except  that  the  lower  case  "r"  is 
replaced  with  a  lower  case  "d" . 


d(0:l) 

refers  to  display  register  segment  0,  register  1. 

Segment  and  element  addresses  start  at  0.  The  number  of 
display  register  segments,  and  the  number  of  display  registers 
within  each  segment,  varies  as  determined  by  the  current  AM 
conf iguration . 

7.16.  Monitor  Attribute 

The  monitor  consists  of  eight  attributes  values  which  are: 

X — represents  number  of  horizontal  pixels  (natural) 
y--represents  number  of  vertical  pixels  (natural) 

V — represents  screen  height  in  inches  (natural) 
h — represents  screen  width  in  inches  (natural) 
i — represents  intensity  capability  (natural) 
c — represents  number  of  color  planes  (natural) 
b--current  background  color  (color) 
d--selected  display  register  to  view 
(display  register  address) 

A  monitor  attribute  is  represented  by  a  dash  followed  by 

one  of  the  above  characters  for  the  indicated  attribute. 

-X 

-y 

-b 

are  all  legal  monitor  attribute  atoms. 

7.17.  Stack  Address 

A  stack  address  has  only  one  component;  the  segment  address 
Stack  addresses  are  specified  by  prepending  a  lower  case  "s" 
to  an  unsigned  decimal  or  hexadecimal  constant  enclosed  within 
parentheses . 

s(2) 

refers  to  stack  segment  2. 

Stack  addresses  begin  at  0.  The  number  of  stacks  depends 
upon  AM's  configuration. 

7.18.  File  Addresses 

File  address  atoms  may  not  appear  in  a  program  except  within 
typed  values.  File  address  atoms  are  represented  as  unsigned 
integer  or  hexadecimal  constants. 

File  addresses  start  at  0.  The  number  of  files  which  may 
be  open  at  one  time  is  determined  by  the  current  AM  configura¬ 
tion.  The  first  three  file  addresses  (0,1,2)  are  normally 
opened  automatically  by  AM  when  a  program  is  loaded. 


7.19.  Pidlist 


Pidlist  atoms  are  composed  of  one ’ or  more  concatenated 
ASCII  characters  and  form  single  strings  that  must  not  be 
empty.  They  are  surrounded  by  angle  brackets. 

<name> 

<id> 

<grade_l> 

are  all  legal  pidlist  atoms. 

7.20.  Pidsetlist 

This  type  represents  a  number  of  zero  or  more  pidlists, 
separated  by  commas  and  enclosed  within  a  set  of  angle 

brackets . 

<  name , age , grade  > 

<  > 

are  both  legal  pidsetlist  atoms. 

7.21.  Vallist 

Vallists  are  represented  like  pidlists  as  strings  of  one 
or  more  concatenated  ASCII  characters.  Type  distinction  is 
made  in  accordance  with  the  context  in  which  they  appear. 
Arithmetic  operations  on  vallist  atoms  are  not  possible  since 
they  are  treated  as  characters. 

<123> 

<A> 

are  legal  vallist  atoms. 

7.22.  Valsetlist 

Analogous  to  the  pidsetlist,  valsetlist  atoms  are  composed 
of  zero  or  more  vallists,  separated  by  commas  and  enclosed 

within  a  set  of  angle  brackets.  Since  a  valsetlist  atom  is 
actually  used  to  define  a  certain  domain  of  values,  it  most 
likely  will  be  of  the  following  form: 

<1,2,3,4,17,123> 

■^A,B,C,D,E,P> 

< Monterey , San_Diego> 

<  > 

but 

< John , Cindy ,Monterey> 
would  also  be  a  legal  vaJsetlist  atom. 
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7.23.  Proplist 


Proplists  are  composed  of  ordered  pairs  that  consist  of  a. 
pidlist  and  a  valsetlist,  additionally  enclosed  within  angle 
brackets  and  separated  by  a  comma  " , " . 

<  <name>, < John, Cindy, Mark >  > 

<  <grade>  ,  <A.,  A- ,B+>  > 

are  legal  proplist  atoms. 

7.24.  Propsetlist 

Propsetlist  atoms  are  represented  by  zero  or  more  prop- 
lists,  additionally  enclosed  within  angle  brackets  and  separated 
by  commas  Since  a  proplist  consists  of  the  ordered  pair 

pidlist  and  valsetlist,  a  propsetlist  atom  also  contains  a 
number  of  ordered  pairs. 

<  <  <name>, <John, Cindy, Mary>  >, 

<  <age> , <20 , 10 , 30 , 17 , 65>  >  > 

is  a  legal  propsetlist  atom. 

7.25.  Pvallist 

This  type  is  composed  of  the  ordered  pair  pidlist  and 
vallist  separated  by  a  comma  " , "  and  additionally  enclosed 
within  angle  brackets. 

<  <name> , < John>  > 

<  <name> , <Cindy>  > 

<  <age>,<17>  > 

are  legal  pvallist  atoms. 

7.26.  Pvalsetlist 

A  pvalsetlist  atom  consists  of  zero  or  more  pvallists, 
separated  by  commas  and  additionally  enclosed  within  angle 

brackets.  It  is  arranged  as  a  number  of  ordered  pairs. 

<  <  <name> , <John>  >,<  <age>,<25>  >,  <  <city>  <Monterey>  >  > 

<  <>  > 

are  both  legal  pvalsetlist  atoms. 

7.27.  Objlist 

Objlists  are  composed  of  zero  or  more  different  pvallists 
and  can  be  considered  as  particular  pvalsetlists .  An  objlist 
consists  of  a  number  of  ordered  pairs  that  like  a  pvalsetlist, 
are  enclosed  within  an  additional  set  of  angle  brackets  and 
separated  by  commas  It  can  be  empty,  although  this  would 

not  be  meaningful. 


<  <  <naine> ,  <John>  >  > 

<  <  <name> , <Cindy>  >,<  <sex> , <female>  >,<  <age>,<20>  >  > 

<  <>  > 

are  legal  objlist  atoms. 

7.28.  Classlist 

This  type  is  represented  by  zero  or  more  obj lists,  addi¬ 
tionally  enclosed  within  angle  brackets  and  separated  by  commas 
It  is  mandatory  that  all  objlists  belonging  to  the  same 
classlist  are  equally  structured.  That  is,  their  pidlist 
atoms  must  be  identical. 

<  <  <  <name>,<John  >  >,<  <age>,<25>  >  >, 

<  <  <name> , <Cindy>  >,<  <age>,<19>  >  >, 

<  <  <name>,<Paul  >  >,<  <age>,<20>  >  >  > 

is  a  legal  classlist  atom. 

7-29.  Db 1 i s  t 

The  dblist  is  composed  of  zero  or  more  classlists  which 
are  additionally  enclosed  within  angle  brackets  and  separated 
by  commas  An  objlist  atom  can  only  be  contained  in  the 

dblist  if  it  is  part  of  a  classlist  that  itself  must  be  contained 
in  the  dblist.  Since  the  structure  is  top-down,  a  pidlist  not 
included  in  any  classlist  may  be  comprised  in  the  dblist,  but 
never  the  reverse. 

The  following  shows  a  legal  dblist  atom: 

<  <  <  <  <name> , < John >  >,<  <score> , < 375>  >  >, 

<  <  <name> , <Mary>  >,<  <score> , <380>  >  >  >, 

<  <  <  <course> , <CS4600>  >,<  <room>,<13>  >,<  <hours > , < 4 . 0 >  >  >, 

<  <  <course> , <OR3333>  >,<  <room>,<42>  >,<  <hours> , <4 . 5>  >  >  > 

<  <  <  <ID>,<ab>  >,<  <est>,<rl9>  >  >, 

<  <  <ID>,<xy>  >,<  <est>,<o23>  >  >, 

<  <  <ID>,<vw>  >,<  <est>,<a95>  >  >  >  > 

The  database  structure  is  simple  and  can  easily  be  disclosed. 

The  first  list  of  this  structure  always  corresponds  to  the 
first  object  class,  while  the  first  list  of  an  object  class  is 
equivalent  to  its  first  object.  Then  the  first  list  of  an 
object  represents  its  first  property  value  which  itself  contains 
the  property_id  as  first  element  and  the  corresponding  value  as 
its  second. 

7.30.  Qaddress 

The  only  component  of  a  queue  address  is  the  segment  address. 
Queue  addresses  are  specified  by  prepending  a  lower  case  "q"  to 


an  unsigned  decimal  or  hexadecimal  constant  enclosed  within 
parentheses . 

q(l) 

refers  to  queue  segment  1. 

8.  Typed  Values 

Some  of  the  atomic  types  may  also  appear  as  typed  values 
in  certain  instructions  and  directives.  A  typed  (immediate) 
value  is  represented  as  an  ordered  pair  consisting  of  a  key¬ 
word  representing  the  type,  and  the  atom  itself,  separated  by 
a  comma  and  enclosed  within  curly  braces 

f int. 100 } 

represents  the  integer  value  100. 

{addr. (1:100) } 

represents  memory  address  value  (1:100). 

A  list  of  the  types  which  may  be  used  as  immediate  values 
alongside  the  corresponding  keywords  appears  below: 

bool — boolean 

nat--natural 

int--integer 

char — character 

string--character  string 

in tens --in tensity 

color--color 

pnt--point 

ret- -rectangle 

addr — memory  address 

file--file  address 

pidlist — property  id  list 

pidsetlist--prnperty_idset  list 

val list--value  list 

val setlist--valueset  list 

proplist — property  list 

propsetlist--propertyset  list 

pvallist — propertyvalue  list 

pvalsetlist — propertyvalueset  list 

ob j list--ob ject  list 

classlist  objectclass  list 

dblist — database  list 

Immediate  values  are  used,  as  in  conventional  assembly  languages 
for  loading  constants  into  cells,  initializing  storage,  pushing 
parameters  to  subroutines  on  the  stack,  and  so  on. 

A  special  syntax  may  be  applied  when  expressing  typed  values 
for  the  define  storage  and  define  directives.  The  type 


keyword  may  be  followed  by  a  list  of  atoms  of  the  appropriate 
type,  separated  by  commas. 

' { int ,1,2, 3, 4, 5, 6, 7, 8} 

shows  an  example  of  this. 

9.  Expressions 

An  expression  may  be  substituted  anywhere  an  integer  or 
natural  atom  is  called  for.  The  expression  must  be  a  sequence 
of  integer/natural  atoms  (and  symbolic  constants  equated  to 
integer/natural  atoms)  separated  by  operators  and  grouping 
symbols  which  evaluates  to  an  atom  of  the  type  called  for 
where  the  expression  is  used. 

9.1.  Expression  Operators 

Legal  operators  are  (in  order  of  increasing  precedence): 

or 
and 

addition  and  subtraction 
multiplication,  division,  and  modulus 
unary  minus 

Expressions  may  be  grouped  using  parentheses 


10.  Notation 

Throughout  the  rest  of  this  manual,  the  following  notational 
conventions  will  be  used  to  describe  the  syntax  of  directives 
and  instructions. 

A  -  atom 

V  -  typed  value 

N  -  natural  atom 

I  -  integer  atom 

M  -  memory  address  atom 

R  -  register  address  atom 

D  -  display  register  address  atom 

C  -  either  a  display  or  a  high  speed  register  address  atom 
T  -  monitor  attribute  atom 
S  -  stack  address  atom 

<  >  -  items  enclosed  within  angle  brackets  are  arguments 
[]  -  items  enclosed  in  square  brackets  are  optional 

<ea>  -  effective  address 
<ev>  -  effective  value 
Q  -  queue  address  atom 


AMASM  emits  object  code  and  directives  using  AM  I/O 
modules.  The  object  module  is,  thus,  directly  readable  by  AM. 

A  linker  and  loader  may  be  written  either  in  a  high  level 
language,  or  AM  assembler. 

The  data  and  object  module  formats  described  below  are  a 
direct  reflection  of  AM's  tagged  architecture.  The  following 
conventions  will  apply: 

-  All  numbers  shown  are  in  hexadecimal. 

-  The  letter  "H"  is  a  place  holder  signifying  any  4-bit  value. 

-  The  letter  "D"  is  a  place  holder  signifying  any  32-bit  value 

-  The  letter  "P"  is  a  place  holder  signifying  a  32-bit  pointer 

-  The  general  form  of  a  typed  value  is 


where  "tag"  is  a  ] 6-bit  type  field,  and  "val"  is  either  an 

8  to  32-bit  value  or  a  32-bit  pointer. 

Note  the  following: 

-  Character  string  atoms  and  values  have  a  16-bit  size  field 
inserted  after  the  type  field  which  indicates  the  number 
of  characters  in  the  value  field  (including  the  ter¬ 
minating  null) .  This  size  field  is  omitted  in  memory 
(since  it  is  not  needed)  and  replaced  by  a  pointer  to 
the  string. 

-  Instruction  values  have  a  32-bit  pointer  following  the 
type  field,  which  points  to  an  array  of  values.  The 
first  value  is  the  opcode  followed  by  the  operands. 

The  number  of  operands  is  encoded  in  the  opcode. 

-  Form  values  have  a  32-bit  pointer  to  a  form  header. 

The  header  contains  the  form's  rectangle  and  a  pointer 
to  the  cmap  which  is  an  array  of  colors.  The  length 
of  the  cmap  is  determined  from  the  form's  rectangle. 

-  Font  values  have  a  32-bit  pointer  to  a  fo..t  header. 

The  header  contains  the  font'  rectangle  and  a  128  member 
array  of  cmap  pointers. 

-  All  list  atoms  and  values  with  the  exception  of  the 
dblist  type  have  a  16-bit  size  field  thar  is  inserted 
after  the  type  field  and  indicates  the  number  of  charac¬ 
ters  contained  in  the  value  field.  Similar  to  the 
string  type,  this  size  field  i--^  replaced  in  memory  by 

a  pointer  to  the  corresponding  list. 

-  Dblist  atoms  and  values  have  a  32-bit  size  field  in¬ 
serted  after  the  type  field  which  indicates  the  number 
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of  characters  in  the  value  field  and  represents  the  total 
number  of  characters  contained  in  the  database.  In 
memory  the  size  field  is  replaced  by  a  32-bit  pointer  to 
the  dblist. 


A  number  of  the  formats  listed  below  are  not  described  else 
where  in  this  manual  since  they  are  either  not  accessible  to 
the  programmer,  or  are  implied  by  context. 

11.1.  Atom  Formats 


boolean  -  j  QQQI 
natural  -  I  0002 


HH 


HHHH 


integer  -  1  0003  1  ! HHHH i 


character  -  0004 


HH 


character  string  -  j  0005  j  |T~[  I  HH.  .  .  00 


intensity  -  10006 

ITh] 

color  -  j  0007 ; 

[  IhH  HH  HH! 

point  -  1 0008 

[  1 DD 

rectangle  -  10009 

[  IT7  1  PPPP 

-cmap  array- 


-128  P's- 


font  -  I OOOB !  I P I  I  DP  DP 
ptblt  -  I OOOCi  |Tf  jPPPP  PDPP  PPPP  HH 


memory  address  -  1 0030  |  I'p7 


register  address  -  1 0031  [  1*57 

display  register  address  -  1 0032 1  I'F] 
monitor  attribute  -  | 0033  | 
stack  address  -  | 0034  | 
file  address  -  10035 


HH 


HHHH 


monadic  operator  -  |0040 


I  HHHH 


dyadic  operator  -  i0041 
triadic  operator  -  | 0042 


HHHH 


HHHH 


quadadic  operator  -  | 004 3 
sexadic  operator  -  | 0044 
octadic  operator  -  [0045 


HHHH 


HHHH 


HHHH 


relational  operator  -  |  0046  j  | HHHH 
boolean  comparator  -  | 0047 
pidlist  -  I  POOP !  IT]  I HH. . . 00 


IHHHH 


vallist  -  I OQOF  | P]  IHH. . .00 
valsetlist  -  |  0010  |  |T[  jHH. . .00 

proplist  -  I  0011 1  |T7  I HH ...  0 0 

propsetlist  -  |  0012  |  |'P~|'  |  HH .  .  .  O'O' 

pvallist  -  I  0013  [  1^  |HH. . .00 

pvalsetlist  -  |  0014  |  |'F]  j  HH .  .  .  P'S" 

Ob j list  -  !  0015  I  |HH. . .00 | 

classlist  -  1  0016  I  IT!  iHH. . .00  I 


dblist  -  ! 0017  I 
qaddress  -  | 0036 


Value  Formats 


boolean  - 
natural  - 


0202 


I HHHH I 
HHHH  1 


integer  -  | 0203 | 
character  -  10204 


character  string  -  | 0205  |  |T]  |  HH  ■ 

intensity  -  | 0 2 0 6 |  | HH | 


color  -  10207 


HH  HH  HH, 


point  -  i  0208 !  [pj  !3d] 
rectangle  -  |  0209  !  |T]  I^DDD | 

form  -  I  020A  |  |~p7  |  DD  DD  |  |~p] 


-cmap  array 


font  - 


ITT  I DD  DD|  I-128P' s- 


memory  address  -  | 0230 |  I D | 
register  address  -  | 0231 j  IT] 
display  register  address  -  | 0232 
monitor  attribute  -  ! 0233 |  1 HH ! 


HHHH  i 


HHHH  I 


stack  address  -  | 0 2 3 4 
file  address  -  | 0235 | 
instruction  -  ! 0250 | 


pidlist  -  I  020D  |  fHH.  .  .  00 

pidsetlist  -  |  020E |  |T]  j  HH . . .  OT 

vallist  -  I 020F |  |T]  |HH. . .00 

valsetlist  -  I  0210  I  ITT  I HH ...  00 


vallist  -  I 020F 


zero  or  more  operand  atoms 


valsetlist  -  0210 


proplist  -  I  0211  |HH.  .  .00  ' 

propsetlist  -  |  0212  j  [T]  |  HH.  .  .  Q5~[ 
pvallist  -  I  0213 |  |HH. . . 00  j 

pvalsetlist  -  |  0214 |  IT]  I HH. . . OTl 
obj]ist  -  I  0215  I  |T~[  |HH.  .  .00  ; 
classlist  -  I  0216 |  |T]  |HH. . .00 | 

dblist  -  I  0217  I  lYi  I D. . .00 
qaddress  -  |  02 36  |  I'D] 


11.3.  Object  Module  Format 

The  structure  of  an  object  module  is  very  simple.  The 
only  object  always  found  is  a  leading  org  directive.  Next, 
any  symbols  were  declared  global  or  external  in  the  source 
module,  a  pseudo  instruction  will  be  emitted  for  each  such 
symbol.  The  rest  of  the  file  contains  executable  and  pseudo 
instructions  emitted  as  they  occur  in  the  source. 


12.  Assembler  Directives 


AMASM  recognizes  the  following  directives: 

equ  -  equate 
org  -  absolute  origin 
rorg  -  relative  origin 
extern  -  external  symbol 
globl  -  global  symbol 
trace  -  trace  execution 
ds  -  define  stroage 

dc  -  define  constant 

Directives  do  not  produce  code  which  will  be  executed  by  AM, 
but  they  may  cause  linker/loader  instructions  to  be  emitted. 
The  meaning  and  syntax  of  each  directive  is  described  in  the 
following  pages- 


EQU 


Equate 


EQU 


Syntax : 

<name>  equ  <equivalence> 
where : 

<name>  is  any  legal  identifier 
<equivalence>  is  any  atom  or  typed  value 

Description : 

The  symbol  <name>  is  assigned  the  value  of  <equivalence> . 
Elsewhere  in  the  source  module,  the  symbol  may  be  used  in  place 
of  a  literal  value  of  the  same  type  as  <equivalence>  using  the 
following  syntax: 

-  If  the  symbol  represents  a  memory  address  atom,  the  symbol 
may  be  used  directly. 

-  If  the  symbol  represents  a  typed  (immediate)  value,  it 
must  be  enclosed  in  curly  braces 

-  If  the  symbol  represents  an  integer  or  natural  atom,  it 
must  be  preceded  by  a  pound  sign 

Example ; 


propseg 

equ 

(0:0) 

dataseg 

equ 

(1:100) 

offset 

equ 

10 

datafile 

equ 

file, 3 

org 

progseg 

move 

{ addr ,data } , r (0 : 0 ) 

move 

{int,100},r{0:0)@#offset 

push 

{string , "test.dat" ) s ( 0) 

push 

{datafile} ,s (0) 

push 

{ int , 0 } , s (0) 

push 

{ int,0  )  ,s (0) 

open 

stop 

s(0) 

org 

dataseg 

data 

ds 

100 

"progseg”  and  "dataseg"  are  equated  to  memory  address  atoms, 
"offset"  is  equated  to  the  integer  atom  10. 

"datafile"  is  equated  to  the  file  address  value  (file, 3). 


ORG 


Absolute  Origin 


Syntax: 

org  [M] 
Description : 


The  location  counter  is  reset  to  M,  if  specified;  other 
wise  it  remains  unchanged.  All  memory  addresses  and  labels 
specified  after  an  org  directive  up  to  the  next  org  or  rorg 
directive  not  explicitly  expressed  as  displacements  are 
treated  as  absolute  addresses.  Code  generated  after  an  org 
directive  up  to  the  next  org  or  rorg  directive  is  not 
relocatable . 


Example : 


data 


org 

move  (0:0)  ,r(0:0) 
org  (1:0) 

ds  ( int, 100 } , {nat , 0 } 


Format : 


102501 


lisoil 


I  0230 


IB 


RORG  Relative  Origin  RO 

Syntax : 

rorg  [M[ 

Description : 

The  location  counter  is  reset  to  M,  if  specified;  other¬ 
wise  it  remains  unchanged.  All  memory  addresses  and  labels 
specified  after  a  rorg  directive  up  to  the  next  org  or  rorg 
directive  are  computer  as  displacements-  Code  generated  after 
a  rorg  directive  up  to  the  next  org  or  rorg  directive  is 
relocatable  (program  counter  independent) . 

Example : 

rorg 


move  { int , 100 }, data 

jsr  stuff 

stop 


data  ds  10 

In  the  above  example,  the  move  would  be  emitted  using 
destination  program  counter  relative  addressing. 


Format : 


EXTERN 


External  Symbol 


EXTERN 


Syntax : 

extern  <name>... 
where : 

<name>  is  any  legal  identifier 
Description : 

The  list  of  symbols  is  made  visible  to  the  current  module 
and  is  assumed  to  be  defined  elsewhere.  An  error  is  flagged 
if  a  symbol  in  the  list  is  not  referenced  somewhere  within 
the  current  module.  It  is  also  an  error  for  any  symbol  in 
the  list  to  be  defined  within  the  current  module. 

Example : 


extern  expon 

push  { int , 100  } , s (0) 
jsr  expon, s(0) 


Format : 

For  each  symbol  decalred  external,  an  extern  pseudo  op  is 
emitted,  followed  by  a  string  containing  the  symbol. 


GLOBL 


Global  Symbol 


GLOBL 


Syntax : 

globl  <name> . . . 
where : 

<name>  is  any  legal  identifier 
Description : 

The  list  of  symbols  is  made  visible  to  external  modules. 
Each  name  in  the  list  must  be  defined  as  a  memory  address 
somewhere  within  the  current  module. 

Example : 

gl  :)bl  test ,  data 

test : 

move  (0:0) ,r(0:0) 
stop 

data  ds  10 

"test"  and  "data"  are  made  visible  to  other  modules. 
Format : 

For  each  symbol  declared  global,  a  globl  pseudo  op  is 
emitted,  followed  by  a  string  containing  the  symbol,  followed 
by  a  memory  address  representing  the  value  of  the  symbol. 


TRACE 


Trace  Execution 


TRACE 


Syntax : 

trace  <f lag> , <toggle> 

where : 

<fiag>  is  "-t"  for  normal  trace  and  "-x"  is  for  extended 
trace 

<toggle>  is  "+"  for  on  and  for  off 

Description : 

A  trace  of  the  programs  execution  is  available  in  two 
modes,  normal  and  extended.  The  norm.al  mode  traces  the  main 
function  calls  and  the  major  paths  through  them.  The  extend 
mode  includes  the  normal  trace  plus  memory  allocation  calls  and 
creation  of  temporary  values.  The  trace  directive  may  be 
selected  in  the  command  line  when  AM  is  invoked,  or  embedded 
in  the  source  code  to  enable  trace  over  selected  portions  of 
the  program. 

Example; 

progseg  equ  (0:0) 

org  progseg 
move  { addr ,data} , r { 0 : 0) 
trace  -t,+ 

move  { int , 100 } , r (0 : 0) @ 
trace  -t,- 
push  1 int , 0  }  , s  (0 ) 
stop 

data  ds  100 

Eormat : 

0250  j  |T800l  j  0204  |  |W]  |  0203  |  |  KHHH  ' 


DS  Define  Storage  DS 

Syntax : 

[  <nanie>  ]  ds  N  [V.  .  .  ] 

[<name>]  ds  [N]  V... 

where : 

<nanie>  is  an  optional  identifier 

ds  permits  a  list  of  atoms  to  follow  the  type  keyword  of 
each  value. 

Description : 

ds  allocates  storage  for  values  starting  at  the  current 
value  of  the  location  counter. 

-  If  N  is  specified  and  17  is  greater  than  or  equal  to  the 
number  of  values  in  the  list,  space  for  N  values  is 
allocated  and  the  location  counter  is  incremented  by  N. 

-  If  N  is  specified  and  N  is  less  than  the  number  of  values 
in  the  list,  N  is  ignored. 

-  If  N  is  not  specified,  the  amount  of  storage  allocated 
is  equal  to  the  number  of  values  in  the  list.  The  loca¬ 
tion  counter  is  incremented  by  this  number. 

-  If  a  value  list  is  specified,  the  allocated  cells  will 

be  initialized  to  those  values,  beginning  with  the  first. 

-  Cells  allocated  but  not  initialized  are  considered  to 
hold  undefined  values.  It  is  an  error  to  attempt  to 
read  an  undefined  value. 

Example : 


data  1 

ds 

10 

data2 

ds 

10 { int , 100 } , i nat , 0,20,40} 

data3 

ds 

{char , ' a  '  , ' b '  } 

ds 

{ string, "this  is  a  string  value" 

The  first  ds  allocates  10  values  and  leaves  them  undefined 
"datal"  may  be  used  to  index  into  those  values. 

The  second  also  allocates  10  values,  but  initializes  the 
first  to  the  integer  100,  and  the  next  3  to  the  naturals 
0,  20,  and  40.  The  last  6  values  are  left  undefined. 

The  third  ds  shown  allocates  2  character  values. 


The  fourth  allocates  a  single  string  value.  No  identi 
fier  was  specified. 

Format : 

A  typed  value  is  emitted  for  each  value  in  the  list.  I 
addition,  ds  will  emit  an  org  pseudo  op  (see  org)  whenever 
the  number  of  values  in  the  value  list  is  less  than  N. 


DC 


Define  Constant 


DC 


Syntax: 

[ <name> ]  dc  V. . . 
where ; 

<name>  is  an  optional  identifier 

dc  permits  a  list  of  atoms  to  follow  the  type  keyword  of 
each  value. 

Description : 

dc  allocates  and  initializes  storage  from  a  list  of  values 
starting  at  the  current  value  of  the  location  counter. 

Example : 

data!  dc  { char , ' a  * , ' b ' } 

dc  { string , "this  is  a  string  value"} 

The  first  ds  shown  allocates  2  character  values. 

The  second  allocates  a  single  string  value.  No  identi¬ 
fier  was  specified. 

Format : 


A  typed  value  is  emitted  for  each  value  in  the  list. 


13.  Addressing  Modes 


AM  supports  11  addressing  inodes: 


d 

r 

ri 

rid 

ridn 

m 

mi 

per 

j. 

a 

s 

q 


display  register  direct 
register  direct 
register  indirect 

register  indirect  with  displacement 

n-level  register  indirect  with  displacement 

memory  absolute 

memory  indirect 

program  counter  relative 

immediate  value 

immediate  atom 

stack  direct 

queue  direct 


Like  other  more  familiar  processors,  not  all  AM  instructions 
can  use  all  of  the  addressing  modes. 


In  addition,  AMASM  supports  address  expressions,  which 
provides  a  rudimentary  indexing  capability. 

13.1.  Display  Register  Direct 

The  form  operand  is  in  the  display  register. 


Syntax:  D 

Format : 

' 0232 [ 

13.2.  Register  Direct 

The  operand  is  in  a  register. 

Syntax:  R 

Format : 

I  0231  I 

13.3,  Register  Indirect 

The  address  of  the  operand  is  in  a  register. 
Syntax:  R@ 

R  -  holds  the  operand  address 


Format : 


13.4.  Register  Indirect  with  Displacement 

The  address  of  the  operand  is  the  sum  of  the  address  in 
register  and  an  integer  displacement. 

Syntax:  R@I 

R  -  holds  a  base  address 

I  -  an  integer  displacement 

Format : 

'  0231  I  I  0203  !  !  HHHH  ’ 

13.5.  N-level  Register  Indirect  with  Displacement 

The  address  of  the  operand  is  the  sum  of  the  address  ob 
tained  from  the  nth  link  in  a  chain  of  dynamic  links  and  an 
integer  displacement. 

Syntax:  RN@I 

R  -  holds  the  current  frame  pointer 

N  -a  non-negative  frame  reference 

I  -  an  integer  frame  displacement 

(RN@I)  is  equivelent  to  R@I) 

Format : 

I  0231  I  I  0202  I  I  HHHH  1  |~0203  |  |  HHHH  ! 

13.6.  Memory  Absolute 

Syntax:  M 

M  -  the  operand  address 

Format : 

I  0230  I 

13.7.  Memory  Indirect 

The  address  of  the  operand  is  in  a  memory  cell. 

Syntax:  M@ 

M  -  a  pointer  to  the  operand  address 


Format : 


13.8.  Program  Counter  Relative 


The  address  of  the  operand  is  the  sum  of  the  program  counter 
and  an  integer  displacement. 

Syntax:  M 

M  -  the  operand  address 

The  specified  address  must  be  in  the  same  module  as  the  instruc¬ 
tion.  The  assembler  automatically  computes  the  displacement. 
Program  counter  relative  is  specified  for  a  block  by  placing 
a  rorg  directive  at  the  top  of  the  block. 

Format : 

I  0203  !  1^ 

13.9.  Immediate  Value 


The  operand  is  an  immediate  value. 
Syntax:  V 

V  -  any  typed  value 

Format : 

itag  I  i  valu  | 

13.11.  Stack  Direct 


The  operand  is  a  stack. 

Syntax:  S 

Format : 

I  "0217]  1]^ 

13.12.  Queue  Direct 

The  operand  is  a  queue. 
Syntax:  Q 

Format : 


!  0236 


in 


14.  Instruction  Set 

The  AM  instruction  set  is  simple  but  powerful.  The  rigid 
data  types  make  it  meaningless  to  specify  operations  like  shift 
and  mask,  thus  removing  some  of  the  programmer's  freedom  to 


muck  with  data  in  arbitrary  ways.  The  tagged  architecture  wil 
detect  errors  like  jumping  to  data,  or  accessing  instructions 
as  data,  as  well  as  the  .more  common  bounds  checking  performed 
by  runtime  libraries. 

141.  Machine  Errors 

The  following  errors  are  detected  by  AM  during  loading  and 
execution : 

-  attempt  to  execute  a  non-instruction 

-  attempt  to  execute  an  illegal  instruction 

-  memory  segment  not  defined 

-  memory  segment  overflow 

-  memory  segment  underflow 

-  register  segment  not  defined 

-  register  segment  underflow 

-  register  segment  underflow 

-  display  register  segment  not  defined 

-  stack  segment  not  defined 

-  undefined  monitor  attribute 

-  <file>  contains  unresolved  references 

-  attempt  to  convert  negative  int  to  nat 

-  no  predecessor  to  zeronat 

-  no  predecessor  to  minintens 

-  no  successor  to  m.axintens 

-  addition  illegal  with  nullintens 

-  subtraction  illegal  with  nullintens 

-  gtintens  illegal  with  nullintens 

-  Itintens  illegal  with  nullintens 

-  geintens  illegal  with  nullintens 

-  leintens  illegal  with  nullintens 

-  illegal  color  definition 

-  form  is  not  correct  size  for  font 

-  icon  is  undefined 

-  unknown  operator  to  applymop 

-  unknown  operator  to  applydop 

-  unknown  operator  to  applytop 

-  unknown  operator  to  applyqop 

-  unknown  operator  to  applysop 

-  unknown  operator  to  applyoop 

-  unknown  operator  to  applyrop 

-  unknown  operator  to  applybop 

-  type  error  -  GT 

-  type  error  -  GE 

-  type  error  -  LT 

-  type  error  -  LE 

-  no  more  segment  available 

-  attempt  to  free  invalid  memory  segment 

-  attempt  to  free  non-allocated  segment 

-  stack  empty 

-  stack  overflow 

-  stack  underflow 


file  already  open 

unable  to  close  file 

unable  to  open  <file> 

file  already  closed 

file  not  open 

file  not  open  for  reading 

file  not  open  for  writing 

reading  file,  type  not  recognized 

error  reading  file 

writing  file,  type  not  recognized 

invalid  memory  segment 

memory  segment  not  allocated 

invalid  memory  address 

invalid  register  segment 

invalid  register  address 

invalid  stack  segment 

invalid  file  descriptor 

attempt  to  return  head  of  null  string 

value  not  of  type  bool 

atom  not  of  type  bool 

value  not  of  type  int 

atom  not  of  type  int 

value  not  of  type  nat 

atom  not  of  type  nat 

value  not  of  type  char 

atom  not  of  type  char 

value  not  of  type  string 

atom  not  of  type  string 

value  not  of  type  ilev 

atom  not  of  type  ilev 

value  not  of  tyep  coir 

atom  not  of  type  coir 

value  not  of  type  pnt 

atom  not  of  type  pnt 

value  not  of  type  ret 

atom  not  of  type  ret 

value  not  of  type  form 

atom  not  of  type  form 

value  not  of  type  font 

atom  not  type  font 

value  not  of  type  ptblt 

atom  not  of  type  ptblt 

value  not  of  type  mad 

atom  not  of  type  mad 

value  not  of  type  rad 

atom  not  of  type  rad 

value  not  of  type  dad 

atom  not  of  type  dad 

value  not  of  type  mattribute 

atom  not  of  type  mattribute 

value  not  of  type  sad 


-  atom  not  of  type  sad 

-  value  not  of  type  file 

-  atom  not  of  type  file 

-  value  not  of  type  mop 

-  atom  not  of  type  mop 

-  value  not  of  type  dop 

-  atom  not  of  type  dop 

-  value  not  of  type  top 

-  atom  not  of  type  top 

-  value  not  of  type  qop 

-  atom  not  of  type  qop 

-  value  not  of  type  sop 

-  atom  not  of  type  sop 

-  value  not  of  type  oop 

-  atom  not  of  type  oop 

-  value  not  of  type  rop 

-  atom  not  of  type  rop 

-  value  not  of  type  bop 

-  atom  not  of  type  bop 

-  value  not  of  type  instr 

-  atom  not  of  type  instr 

-  type  error 

-  queue  segment  not  defined 

-  queue  empty 

-  queue  overflow 

-  queue  underflow 

-  db  already  open 

-  unable  to  close  db 

-  unable  to  open  <db> 

-  db  already  closed 

-  db  not  open 

-  illegal  object  insertion 

-  object  not  contained  in  clas 

-  invalid  queue  segment 

-  atom  not  of  type  pid 

-  value  not  of  type  pid 

-  atom  not  of  type  val 

-  value  not  of  type  val 

-  atom  not  of  type  pval 

-  value  not  of  type  pval 

-  atom  not  of  type  obj 

-  value  not  of  type  obj 

-  atom  not  of  type  db 

-  value  not  of  type  db 

-  atom  not  of  type  1st 

-  value  not  of  type  1st 

All  machine  errors  are  fatal. 


14.2.  Assembler  Errors 


AMASM  will  detect  and  report  the  following  errors: 

-  symbol  not  an  address 

-  symbol  defined  locally 

-  <symbol>  does  not  match  declared  type 

-  relative  memory  indirect  not  permitted 

-  symbol  not  a  value 

-  symbol  not  an  integer 

-  intensity  value  exceeds  range 

-  symbols  declared  but  not  referenced 

-  displacement  from  external  addresses  not  permitted 

-  relative  addressing  not  permitted  between  segments 

-  out  of  symbol  space 

-  symbol  declared  external 

-  symbol  already  defined 

-  symbol  not  of  same  type 

-  impossible  value  for  given  type 

-  syntax  error 

Assembler  errors  are  not  fatal,  but  will  prevent  the  crea 
tion  of  the  object  module  and,  usually,  the  cross-reference 
f  ile . 

14.3.  AM  Operations 

AM  supports  a  useful  set  of  monadic,  dyadic,  triadic, 
quadadic,  sexadic,  octadic,  relational  and  test  operators. 
These  operators  are  to  be  used  with  the  monad,  dyad,  triad, 
quad,sexad,  octad,  if  and  test  instructions.  The  mnemonics/ 
symbols  for  each  operator  along  with  the  data  types  to  which 
each  may  be  applied  are  described  below. 

14.3.1.  Monadic  Operators  (MOP's) 

not  -  boolean  negation 

not  accepts  a  boolean  argument  and  returns  its  negation 
abs  -  absolute  value 

abs  accepts  an  integer  argument  and  returns  is  absolute 
value 

ntoi  -  natural  to  integer 

ntoi  accepts  a  natural  argument  and  converts  it  to  an 
integer 

-  integer  to  natural 

iton  accepts  an  integer  argument  and  converts  it  to  a 
natural 


iton 


len  -  string  length 

len  accepts  a  string  argument  and  returns  its  length  as 
a  natural  number. 

make  -  make  a  string 

This  operator  accepts  a  character  argument  and  returns  a 
string  of  length  1. 

head  -  the  head  of  a  string 

This  operator  accepts  a  string  argument  and  returns  the 
character  at  its  head.  It  is  an  error  to  take  the  head 
of  an  empty  string. 

tail  -  the  rest  of  a  string 

tail  accepts  a  string  argument  and  returns  a  string  con¬ 
taining  all  but  the  first  character.  The  tail  of  an 
empty  string  is  the  empty  string. 

remp, gcmp,bcmp  -  color  components 

remp,  gcmp  and  bcmp  accept  a  color  argument  and  return 
the  respective  red,  green,  or  blue  component  of  the 
color. 

xcord,ycord  -  point  coordinate 

xcord  and  ycord  accept  a  point  argument  and  return  the 
respective  coordinate  integer. 

or igin , corner  -  rectangle  corner  points 

These  operators  accept  a  rectangle  argument  and  return  a 
corner  point.  Origin  returns  the  lower  left  and  corner 
the  upper  right. 

xdim,ydim  -  rectangle  dimensions 

xdim  and  ydim  accept  a  rectangle  argument  and  return  the 
respective  dimension  integer. 

newfrm  -  new  form 

newfrm  accepts  a  rectangle  argument  and  returns  a  new  blank 
form  whose  rectangle  is  the  same  as  the  input  rectangle. 

farea  -  form  area 

farea  accepts  a  form  argument  and  returns  its  rectangle. 

gbits , gbltd , gbltc  -  get  ptblt  rectangles 

These  operators  accept  a  ptblt  argument  and  return  the 
specified  rectangle.  gbits  returns  the  source,  gbltd 
returns  the  destination,  and  gbltc  returns  the  clipping 
rectangle . 


^  ■  v  .■  J 


gbltr  -  get  ptblt  rule 

gbltr  accepts  a  ptblt  argument  and  returns  the  natural 
that  represents  the  copy  rule. 

newfnt  -  new  font 

newfnt  accepts  a  rectangle  argument  and  returns  an  empty 
font  whose  icon  rectangles  are  the  same  as  the  input 
rectangle • 

rctfnt  -  rectangle  of  font 

rctfnt  accepts  a  font  argument  and  returns  its  rectangle, 
lenfnt  -  length  of  font 

lenfnt  accepts  a  font  argument  and  returns  the  number  of 
icons  in  it  as  a  natural. 

makenew  -  make  a  list 

This  operator  accepts  a  list  argument  and  returns  a  new 
list . 

first  -  the  first  list 

first  accepts  a  list  argument  and  returns  the  first  list 
contained  in  it.  It  is  an  error  to  take  the  first  of  an 
empty  list. 

rest  -  the  rest  of  a  list 

rest  accepts  a  list  argument  and  returns  a  list  containing 
all  but  the  first  list.  It  is  an  error  to  apply  this 
operator  to  the  empty  list. 

sofirst  -  set  of  first  lists 

This  operator  accepts  a  list  and  returns  the  set  of  all 
first  lists  contained  in  it.  Applying  sofirst  to  a  list 
which  does  not  contain  at  least  two  sublists  results  in 
an  error. 

14.3.2.  Dyadic  Operators  (OOP's) 
ana , or 

and  and  or  accept  two  boolean  arguments  and  return  a  boolean 
result . 

add , sub , mul , div , mod  -  computational  operators 

These  operators  accept  integer,  natural  or  intensity  argu¬ 
ments  (both  of  the  same  type)  and  return  a  result  of  that 
type.  Divide  by  zero  returns  an  error.  div  discards  any 
remainder.  mod  returns  the  remainder.  mul,  div  and  m.od 
do  not  apply  to  intensity  arguments. 
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cat 


-  string  concatenation 

cat  accepts  two  string  arguments  and  returns  the  concaten¬ 
ation  of  the  first  onto  the  second. 

loc  -  point  location 

loc  accepts  two  integer  arguments  and  returns  the  defined 
point . 

Usage  -  loc(x,y)  where  x  is  the  x  coordinate  integer  and 
y  is  the  y  coordinate  integer. 

area  -  rectangle  definition 

area  accepts  two  unordered  point  arguments  and  returns  the 
defined  rectangle. 

inrct  -  point  in  rectangle 

inrct  accepts  a  point  and  a  rectangle  argument,  checks  if 
the  point  is  inside  the  area  of  the  rectangle,  and 
returns  the  boolean  result. 

Usage  -  inrct (p,r)  where  p  is  a  point  and  r  is  a  rectangle. 

intrct  -  rectangle  intersection 

intrct  accepts  two  rectangle  arguments  and  returns  the 
intersection  rectangle. 

putrct  -  put  rectangle  at 

putrct  accepts  a  point  and  a  rectangle  argument  and  returns 
the  rectangle  with  the  same  area  as  the  input  and  its 
origin  at  the  point  argument. 

Usage  -  putrct (p,r)  where  p  is  a  point  and  r  is  a  rectangle 

mapsp,mapps  -  conversion  operators 

These  operators  convert  points  between  point  coordinates 
and  font  spot  coordinates.  They  accept  a  point  and  a  font 
argument  and  return  a  point.  mapsp  takes  a  spot  coordinate 
and  based  on  the  font  size  returns  its  origin  point,  e.g., 
the  origin  point  of  spot  (2,3)  for  a  10  by  10  font  is 
point  (20,30).  mapps  takes  a  point  and  returns  the  font 
spot  that  it  falls  inside,  e.g.,  the  point  (21,31)  for  a 
10  by  10  font  is  in  spot  (2,3). 

Usage : 

-  mapsp(f,p)  where  f  is  a  font  and  p  is  a  point, 

-  mapps (f,p)  where  f  is  a  font  and  p  is  a  point. 


gcolor  -  get  color 

gcolor  accepts  a  point  and  a  form  argument  and  returns  the 
form's  color  at  that  point. 

Usage  -  gcolor  (p,f)  where  p  is  a  point  and  f  is  a  font, 
fill  -  fill  the  form 

fill  accepts  a  color  and  a  form  and  returns  the  from  with 
all  its  points  set  to  the  color  argument. 

Usage  -  fill{c,f)  where  c  is  a  color  and  f  is  a  font. 

sbits , sbltd , sbltc  -  set  ptblt  rectangles 

These  operators  accept  a  rectangle  and  a  ptblt  argument 
and  return  the  ptblt  with  the  specified  rectangle  set  to 
the  rectangle  argument. 

sbits  sets  the  source,  sbltd  sets  the  detaintion,  and 
sbltc  sets  the  clipping  rectangle. 

Usage  -  sblt_(r,b)  where  r  is  a  rectangle  and  b  is  ptblt. 
sbltr  -  set  ptblt  rule 

sbltr  accepts  a  natural  and  a  ptblt  argument  and  returns 
the  ptblt  with  copy  rule  set  to  the  natural  argume.it. 

Usage  -  sbltr (n,b)  where  n  is  a  natural  and  b  is  ptblt, 
infnt  -  is  icon  in  font 

infnt  accepts  a  natural  and  a  font  argument  and  returns 
a  boolean  result  based  on  whether  the  icon  indexed  by  the 
nautral  argument  is  defined. 

Usage  -  infnt (n,f)  where  n  is  a  natural  and  f  is  a  font, 
dfnt  -  delete  icon 

dfnt  accepts  a  natural  and  a  font  argument  and  returns  the 
font  with  the  indexed  icon  deleted. 

Usage  -  dfnt(n,f)  where  n  is  a  natural  and  f  is  a  font, 
gfnt  -  get  icon 

gfnt  accepts  a  natural  and  a  font  argument  and  returns 
the  form  of  the  icon  indexed. 

Usage  -  gfnt(n,f)  where  n  is  a  natural  and  f  is  a  font, 
un  -  union  of  lists 

un  accepts  two  lists  as  arguments  and  returns  the  union 
of  both. 


int  -  intersection  of  lists 

int  accepts  two  list  arguments  and  returns  the  intersec¬ 
tion  of  both. 

cat  -  list  concatenation 

This  operator  accepts  two  list  arguments  and  returns  the 
concatenation  of  the  first  list  onto  the  second. 

get  -  get  a  list 

get  accepts  two  list  arguments  and  returns  the  list  from 
the  first  argument  that  corresponds  with  the  second.  If 
any  of  the  two  arguments  is  the  empty  list  the  operation 
results  in  an  error. 

de  -  delete  a  list 

This  operator  accepts  two  list  arguments  and  returns  a 
list  that  is  equal  to  the  second  argument  out  reduced  by 
the  list  indicated  by  the  first  argument.  It  is  an  error 
to  apply  de  to  an  empty  list  or  to  specify  a  first  argu¬ 
ment  that  is  not  contained  in  the  second. 

retobj  -  retrieve  an  object 

retobj  accepts  two  list  arguments  and  returns  the  list 
that  corresponds  to  the  second  argument.  If  the  second 
argument  is  the  empty  list  the  result  will  also  be  the 
empty  list. 

14.3.3.  Triadic  Operators  (TCP's) 
dcolor  -  define  color 

dcolor  accepts  three  intensity  arguments  and  returns  the 
defined  color. 

Usage  -  dcolor ( r , g , b )  where  r  is  the  red  intensity,  g  is 
the  green  intensity,  and  b  is  the  blue  intensity. 

pof f St 

poffst  accepts  a  point  and  two  integer  arguments  and 
returns  the  point  that  is  offset  from  the  point  argument 
by  the  integer  arguments. 

Usage  -  pof  fst  (x ,  y ,  p)  ■’where  x  and  y  are  the  offset 
integers  and  p  is  the  reference  point. 

sftrct  -  shift  rectangle 

sftrct  accepts  a  rectangle  and  two  integer  arguments  and 
returns  the  rectangle  formed  by  offsettting  its  origin 
by  the  integer  arguments. 


Usage  -  sf tret (x , y , r )  where  x  and  y  are  the  offset  inte¬ 
gers  and  r  is  the  reference  rectangle. 

scolor  -  set  color 

scolor  accepts  a  color,  a  point  and  a  form  argument  and 
returns  the  form  with  its  point  argument  set  to  the  color 
argument . 

Usage  -  scolor (p , c , f)  where  p  is  the  point,  c  is  the 
color,  and  f  is  the  font. 

invfrm  -  inverse  form 

invfrm  accepts  a  form  and  two  color  arguments  and  returns 
the  form  with  its  fore  and  background  colors  inversed 
by  the  color  arguments. 

Usage  -  invf rm ( fg , bg , f rm)  where  fg  is  the  new  foreground 
color,  bg  is  the  new  background  color,  and  frm  is  the  form 
to  be  inversed. 

sf n t  -  set  font 

sfnt  accepts  a  natural,  a  form,  and  a  font  and  returns  the 
font  with  the  new  icon  inserted  that  is  defined  by  the 
form  and  natural  arguments. 

Usage  -  sf nt ( f rm, n , fnt)  where  frm  is  the  icon  form,  n  is 
the  i.ndex,  and  fnt  is  the  font. 

mod  -  modify  list 

mod  accepts  a  dblist,  an  objlist,  and  a  pvallist  and 
returns  the  dblist  with  the  new  pvallist  inserted  into 
the  appropriate  position  of  the  objlist  identified  by  the 
corresponding  'pid.'  It  is  an  error  to  apply  a  pvallist 
to  an  object  for  which  it  is  not  defined. 

14.3.4.  Quadadic  Operators  (OOP's) 

toffst  -  font  offset 

foffst  accepts  two  integer  arguments  as  an  offset,  a  point 
argument  and  a  font  argument.  It  returns  the  spot  origin 
point  based  on  the  spot  coordinate  offset  from  the  point 
argument,  e.g.,  a  font  size  of  10  by  10  which  is  offset 
2,3  from  point  (5,5)  returns  the  spot  origin  point  at 
(25,35)  . 

Usage  -  f  of  f  st  ( .x ,  y ,  f  nt ,  p)  where  x  and  y  are  the  offset 
integers,  fnt  is  the  basis  font,  and,  p  is  the  reference 


cpfrm  -  form  copyblt 

cpfrm  merges  a  source  and  a  mask  form  with  a  destination 
form  using  the  parameters  in  ptblt.  It  accepts  a  ptblt 
and  three  form  arguments  and  returns  the  resultant  form. 

Usage  -  cpf rm (pb , s ,m, d)  where  pb  is  the  governing  ptblt, 
s  is  the  source  form,  m  is  the  mask  form,  and  d  is  the 
destination  form. 

14.3.5.  Sexadic  Operators  (SOP's) 
drawln  -  draw  line 

drawln  draws  a  line  from  point  y  to  point  z  on  the  destina¬ 
tion  form,  using  the  specified  brush  and  mask  forms.  It 
accepts  two  point  arguments,  three  form  arguments  and  a 
ptblt  argument  and  returns  a  form. 

Usage  -  drawln (x ,y , pb ,b ,m,d)  where  y  is  the  start  point, 
z  is  the  end  point,  pb  is  the  ptblt,  b  is  the  brush  form, 
m  is  the  mask  form,  and  d  is  the  destination  form. 

cpfnt  -  copy  font 

cpfnt  copies  a  font  icon  to  a  designated  point  on  the  des¬ 
tination  form.  It  accepts  a  natural  and  a  font  argument 
which  defines  the  source  form,  a  point  argument  for  the 
target  location,  two  form  arguments  and  a  ptblt  argument 
and  returns  the  resultant  form. 

Usage  -  cpf nt ( p , pb , n , f nt ,m,d)  where  p  is  the  target  location, 
pb  is  the  ptblt,  n  is  the  font  index;  fnt  is  the  font,  m 
is  the  mask  form,  and  d  is  the  destination  form. 

14.3.6.  Octadic  Operators  (OOP's) 
invfnt  -  inverse  font 

invfnt  performs  the  same  operation  as  cpfnt  except  that 
the  font  icon  is  combined  with  inverse  coloring.  It 
accepts  the  same  arguments  plus  two  color  arguments  and 
returns  the  resultant  form. 

Usage  -  invf nt ( fg , bg , p , pb , n , f nt , m, d )  where  fg  is  the  new 
foreground  color,  bg  is  the  new  background  color,  p  is 
the  target  location,  pb  is  the  ptblt,  n  is  the  font  index, 
fnt  is  the  font,  m  is  the  mask  form,  and  d  is  the  destina¬ 
tion  form. 

14.3.7.  Relational  Operators  (ROP's) 

The  relational  operators  are: 

==  -  equality 

>  -  greater  than  • 


>=  -  greater  than  or  equal  to 

<  -  less  than 

<=  -  less  than  or  equal  to 

!=  -  not  equal  to 

They  may  be  applied  to  int,  nat,  char,  string,  intens,  pnt, 
and  1st. 

Tf  ==  or  !=  are  applied  to  arguments  of  different  types, 

==  returns  false,  !=  returns  true.  This  applies  also  to  types 
not  listed  above.  >,>=,<  and  <=  return  an  error  if  their 
arguments  are  not  of  the  same  type. 

Relational  operators  return  a  boolean  result. 

14.3.8.  Test  Operators  (BOP's) 

These  operators  permit  the  programmer  to  test  a  cell  for 
type  before  attempting  to  access  it.  These  are  necessary  be¬ 
cause  AM  considers  it  a  fatal  error  to  read  from  an  undefined 
cell  or  apply  an  operator  of  one  type  on  data  of  another. 

The  test  operators  are  the  same  as  the  type  mnemonics,  plus  a 
mnemonic  for  testing  undefined  values: 

bool 

nat 

int 

char 

string 

intens 

color 

pnt 

ret 

form 

font 

ptblt 

instr 

addr 

file 

undef 

pid 

val 

pval 

ob  j 

db 

1st 


Test  operators  accept  a  typed  value  and  return  true  if  the 
value  is  of  the  specified  type,  false  otherwise.  undef  re¬ 
turns  true  if  a  value  is  undefined,  false  otherwise. 


OFFSET 


Offset  an  Address 


OFFSET 


Syntax : 

offset  I,R 

R  must  contain  a  memory  address  value 

Operation : 

R  +  I  — >  R 

Description : 

The  sum  of  I  and  the  address  in  R  is  stored  in  R. 


Example ; 


offset  20,r{0:0) 


Addressing  Modes: 
I :  a 


R:  r 


Format : 


0250 i  1T[  I  3810  I  I  operands 


LINK 


Link  Frame  and  Allocate 


LINK 


Syntax : 

link  R,N 

Operation : 

R@  -->  address® 

address  -->  R 

Description : 

A  segment  of  N  cells  is  allocated  from  the  heap.  The 
value  stored  in  R  is  save  at  the  base  address  of  the  segment. 
The  segment  base  address  is  returned  in  R. 

This  instruction  is  designed  to  create  dynamic  links  for 
local  environments. 

Example : 

proc;  link  r(0:5),l 

move  r(0:5)2@4,r(0:0) 
add  {  int , 100 } , r ( 0 : 0 ) 
move  r(0:0),r(0:5)2®4 
unlink  r(0:5) 
rts 

Above  is  an  example  of  uplevel  addressing. 

Addressing  Modes; 

R:  r 

N:  a 


UNLINK 


Unlink  and  Free 


UNLINK 


Syntax : 

unlink  R 

Operation : 

R@  — >  R 

Description : 

The  value  in  the  base  address  of  the  segment  pointed  to 

by  R  is  returned  in  R.  The  segment  is  freed. 

Example : 

proc :  link  r(0:5),l 

move  r(0:5)2@4,r(0;0) 
add  ( int , 100 } , r ( 0 : 0 ) 
move  r(0;0),r(0:5)2@4 
unlink  r(0:5) 
rts 

Addressing  Modes: 

R:  r 

Format : 

i  0  2  5  07  I'P]  !  2812  I  i  ope  ran*?] 


GDWIN 


Get  Display  Window  Location 


GDWIN 


Syntax: 

gdwin  D,R 

Operation : 

D  — >  R 

Description : 

The  value  of  the  display  window  origin  point  at  D  is 
stored  in  R. 

Example : 

gdwin  d(0:0),r(0:0) 

Addressing  Modes; 

R:  r 


Format : 


SDWIN  Set  Display  Window  Location  SDWIN 


Syntax : 

sdwin  R,D 

R  must  contain  a  point  value 

Operation : 

R  — >  D 

Description : 

The  display  window  origin  point  at  D  is  set  to  the  point 
value  in  R. 

Example : 

sdwin  r ( 0 : 0 ) ,d (0 : 0 ) 

Addressing  Modes: 

R:  r 


Format : 


GMTR 


Get  Monitor  Attribute 


Syntax : 

gmtr  T , R 

Operation : 

T  — >  R 

Descripti on : 

The  T  value  is  stored  in  R. 

Example : 

gmtr  -b,r(0:0) 

Addressing  Modes: 

R:  r 

Format : 

I  0250  I  1 P  f  {  I  2815  I  . . .  I 281C  j  }  I  operand 


SMTR 


Set  Monitor  Attribute 


Syntax : 

smtr  R,T 

R  must  contain  a  value  appropriate  for  the  selected 
attribute . 

Operation : 

R  — >  T 

Description : 

The  T  value  is  set  to  the  value  in  R 
Example : 

smtr  r ( 0 : 0 ) , -d 

Addressing  Modes: 

R:  r 


Format : 


MONADS 


Monadic  Short 


MONADS 


Syntax: 

<mop>  C 

where : 

<mop>  is  a  monadic  operator 

Operation : 

<mop>  C  — >  C 

Descr iption : 

The  operator  corresponding  to  mop  is  applied  to  C  and 
the  result  stored  in  C. 

Example : 


not  r  (0  :  0 ) 

Addressing  Modes: 

C:  r,d 


Format : 


!  3830 


j  operand 


MONADL 


Monadic  Long 


Syntax : 

<mop>  Cx,Cy 

where : 

<mop>  is  a  monadic  operator 

Operation : 

<mop>  Cx  — >  Cy 

Description : 

The  operator  corresponding  to  mop  is  applied  to 
the  result  stored  in  Cy. 

Example : 


not  r(0;0)  ,r(l  :0) 
farea  d(0:0),r(0:0} 

Addressing  Modes: 

Cx  ;  r  ,  d 
Cy :  r , d 


Format : 
0250 


operands 


MONADL 


Cx  and 


iTy  14831 


MONADLI 


Monadic  Long  Immediate 


MONADLI 


Syntax : 

<mop>  V,C 


where  : 

<mop>  is  a  monadic  operator 

Operation : 

<mop>  V  -->  C 

Description : 

The  operator  corresponding  to  <mop>  is  applied  to  the 
immediate  value  V  and  the  result  stored  in  C. 

Example : 


t  addr , flag } , r ( 1 ; 0 ) 

{ addr , rctsi ze } , d { 0 : 0 ) 

Addressing  Modes: 

V:  i 
C:  r  ,d 


not 

newf rm 


Format : 


DYADS 


Dyadic  Short 


Syntax : 

<dop>  Cx,Cy 

where : 

<dop>  is  a  dyadic  operator 

Operation : 

Cy  ■'dop>  Cs  — >  Cy 

Description : 

The  operation  corresponding  to  <dop 
operands  and  the  result  stored  in  Cy . 

Example : 

and  r ( 0 : 0 ) , r  (0  : 1 ) 
fill  r  (0:0)  ,d(0:0) 

Addressing  Modes: 

Cx:  r,d 
Cy :  r , d 

Format : 

02  50'  I  4833  I  j  operands  | 


DYADL 


Dyadic  Long 


DYADL 


Syntax: 

<dop>  Cx,Cy,Cz 
where : 

<dop>  is  a  dyadic  operator 

Operation : 

Cy  <dop>  Cx  -->  Cz 

Description : 

The  operation  corresponding  to  <dop>  is  applied  to  Cx  and 
Cy  and  the  result  stored  in  Cz. 

Example : 


add  r (0:0) ,r(0:l) ,r(0:3) 
gcolor  r (0 : 0) ,d (0 : 0) , r (0 : 1) 

<dop>  Cx,Cy,Cy  is  equivalent  to  <dop>  Cx,Cy 

Addressing  Modes: 

Cx:  r  ,d 
Cy:  r,d 
Cz  :  r ,  d 


Format : 


DYADLI  Dyadic  Long  Immediate 

Syntax: 

<dop>  V,Cx,Cy 

where : 

<dop>  is  a  dyadic  operator 

Operation : 

Cx  <dop>  V  — >  Cy 

Description : 

The  operation  corresponding  to  <dop>  is  applied  to 
Cx  and  the  result  stored  in  Cy. 

Example : 

add  {  int ,  100.}  ,  r  (0  :  0)  ,  r  (0  : 1) 
gcolor  {pnt /  (0 , 0)  }  ,d (0 : 0 )  , r ( 0 : 0) 

‘'dop>  V,Cx,Cx  is  equivalent  to  <dop>  V,Cx 

Addres.sing  Modes: 

V:  i 
Cx :  r , d 
Cy:  r,d 


DYADLI 


V  and 


Format : 


TRIADS 


Triadic  Short 


TRIADS 


Syntax : 

<top>  Cx,Cy,C2 
where : 

<top>  is  a  triadic  operator 
Operation : 

<top>  Cx,Cy,C2  -->  C2 
Description : 

The  operation  corresponding  to  <top>  is  applied  to  the 
operands  and  the  result  stored  in  C2. 

Example : 


Addressing  Modes 
Cx:  r,d 
Cy:  r,d 
Cz;  r,d 


TRIADL 


Triadic  Long 


TRIADL 


Syntax : 

<top>  Cw,Cx,Cy,C2 
where : 

<top>  is  a  triadic  operator 
Operation : 

<top>  Cw,Cx,Cy  — >  Cz 
Description : 

The  operation  corresponding  to  <top>  is  applied  to  the 
operands  and  the  result  stored  in  Cz. 

Example ; 

SCO lor  r(0:0) ,r(0:l) ,d(0:2) ,r(0:3) 

Addressing  Modes: 

Cw :  r ,  d 
Cx :  r ,  d 
Cy :  r , d 
Cz :  r,d 
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QUADS 


Quadic  Short 


QUADS 


Syntax : 

<qop>  Cw,Cx,Cy,C2 
where : 

<qop>  is  a  quadadic  operator 
Operation : 

' qop  ’  Cw,Cx,Cy,Cz  Cz 

Descripti'^n : 

The  operation  corresponding  to  <qop>  is  applied  to  the 
operands  and  the  result  stored  in  Cz. 

Example : 

cpfrm  r(0:0)  ,d(0:0)  ,r(0:l)  ,d(0:l) 

Addressing  Modes; 

Cw ;  r  ,  d 
Cx;  r,d 
Cy:  r,d 
Cz:  r,d 

Format : 

I  02 50  I  ]T7  I  4839  1  I  operands | 


QUADL 


Quadic  Long 


QUADL 


Syntax : 

<qop>  Cv,Cw,Cx,Cy ,Cz 
where : 

<qop>  is  a  quadadic  operator 
Operation : 

<qop>  Cv,Cw,Cx,Cy  — >  Cz 
Description : 

The  operation  corresponding  to  <qop>  is  applied  to  the 
operands  and  the  result  stored  in  Cz. 

Example : 


cpfrm  r(0:0)  ,r(0:l)  ,r(0:2)  ,rO:3)  ,d(0:0) 

Addressing  Modes: 

Cv:  r,d 
Cw :  r , d 
Cx :  r , d 
Cy :  r ,  d 
Cz:  r,d 

Format ; 

!  0250  I  |T]  I  483a|  I  operands" 


SEXADS 


Sexadic  Short 


SEXADS 


Syntax : 

‘^sop>  Cu,Cv,Cw,Cx,Cy,Cz 
where : 

<sop>  is  a  sexadic  operator 
Operation : 

<sop>  Cu,Cv,Cw,Cx,Cy,Cz  — >  Cz 
Description : 

The  operation  corresponding  to  <sop--  is  applied  to  the 
operands  and  the  result  stored  in  Cz. 

Example : 


drawln  r{0:0)  ,r(0:l)  ,r(0:2)  ,r(0:3)  ,r(0:4)  ,d(0:0) 
Addressing  Modes: 


Cu : 

r,d 

Cv: 

r,d 

Cw: 

r,d 

Cx : 

r  ,d 

Cy ; 

r  ,d 

Cz  : 

r,d 

Format : 

I  02  50;  |'P~[  I  483B I  |  operands  I 
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OCTADS 


Octadic  Short 


OCTADS 


Syntax : 

<oop>  CsCt , Cu, Cv, Cw, Cx, Cy , Cz 
where : 

<oop>  is  a  octadic  operator 
Operation : 

<oop>  Cs , Ct ,Cu ,Cv ,Cw, Cx ,Cy ,Cz  — >  Cz 
Description : 

The  operation  corresponding  to  <oop>  is  applied  to  the 
operands  and  the  result  stored  in  Cz . 

Example : 

invf nt  r(0;0),r(0:l),r(0:2),r(0:3),r(0:4),r(0:5), 
r  (0:6)  ,d(0:l) 

Addressing  Modes: 

Cs :  r ,  d 
Ct:  r,d 
Cu:  r,d 
Cv :  r ,  d 
Cw;  r , d 
Cx :  r ,d 
Cy:  r,d 
Cz :  r,d 

Format ; 

fO 2 5 (!)  I  |?T  I  4  830  I  j  operands 


OCTADL 


Octadic  Long 


OCTADL 


Syntax : 

<oop>  Cr , Cs , Ct , Cu , Cv , Cw , Cx , Cy , Cz 
where : 

<oop>  is  a  octadic  operator 
Operation : 

<oop>  Cr , Cs , Ct , Cu, Cv, Cw , Cx , Cy  — >  Cz 


^  A 


-V'* 


Description : 

The  operation  corresponding  to  <oop>  is  applied  to  the 
operands  and  the  result  stored  in  Cz. 


Example : 


invf nt  r(0:0)  ,r(0:l. )  ,r(0:2)  ,r(0:3)  ,r(0:4)  ,r(0:5)  , 
r  (0:6) ,d(0:0) ,d(0:l) 


Addressing  Modes; 
Cr:  r,d 
Cs :  r,d 
Ct:  r,d 
Cu:  r,d 
Cv :  r , d 
Cw :  r , d 
Cx :  r , d 
Cy:  r,d 
Cz :  r,d 


Format : 


I 0250  [  |TT  [TajE  I  operands 


O  -A**.  •  ••  • 


MOVE 


Move  a  Value 


MOVE 


Syntax : 

move  <eal>,<ea2> 
where : 

<ea>  must  be  one  of  the  addressing  modes  listed  below 
Operation : 

source  — >  destination 
Description : 

The  value  found  at  the  source  address  is  copied  into 
the  destination  address. 

Example : 

move  r(0:0) ,d(0:0) 
move  d(0:l) ,r(0;4) 
move  r(0:0),data 
move  { addr ,data } , r (0 ; 20) 
move  { int , 100 } , r (0 : 20) @ 
move  r(0:20)@10,r(0:30) 

data:  ds  100 

Addressing  Modes: 

• eal > :  d , r , ri , rid , ridn , m, per , i 
<ea2>:  d , r , ri , rid , ridn ,m, per 


Format : 


PUSH 


Push  a  Value 


PUS 


Syntax : 

push  <ea>,S 

where : 

<ea>  is  one  of  the  addressing  modes  listed  below 

Operation : 

source  — >  S 

Description : 

The  source  value  is  pushed  onto  stack  S.  The  programmer 
has  no  access  to  the  stack  pointer. 

Example : 


push  { i nt , 100 } , s (0) 
push  r  (0  : 10)  ,s  (1) 
push  d(0:0) ,s(l) 

Addressing  Modes: 

<ea>:  d ,m, per , r , ri , rid , r idn, i 
S;  s 


Format : 


0250 


iT]{|  H88O7  ,  .  .  I  H887  I }|  operands 


where : 

<ea>  is  one  of  the  addressing  modes  listed  below 

Operation : 

S  -->  destination 

Description : 

The  source  value  is  popped  off  stack  S  and  stored  at  < 
The  programmer  has  no  access  to  the  stack  pointer. 

It  is  an  error  to  attempt  to  pop  a  value  from  an  empty 


stack . 

Example : 

pop  s  ( 0 ) 

.r (0:1) 

pop  s(0) 

,  data 

pop  s(l) 

,d{0:0) 

data  : 

ds  1 

Addressing 

Modes : 

S :  s 

<ea>  :  d 

,m, per , r , ri  , 

rid,ridn 

Format : 


POPX 


Remove  the  Top  of  a  Stack 


P 


Syntax : 

popx  S 

Operation : 

S  — > 

Description ; 

The  top  value  of  stack  S  is  removed. 

It  is  an  error  to  attempt  to  remove  the  top  of  an  em.pt; 
stack . 

Example : 


popx  s(0) 

Addressing  Modes: 

S ,  s 


Format : 

I  0250  [ 


2888 


operands 


MOP 


No  Operation 


Syntax : 
nop 

Operation : 

Description : 

Does  nothing. 
Addressing  Modes: 

Format : 

I  0250  I  1^  1 18A0 ! 


STOP 


Halt  Execution 


STOP 


Syntax : 
stop 

Operation : 

Description : 

Execution  is  terminated. 
Addressing  Modes: 


Format : 


0250 


in 


!  18A1 
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'P 


Syntax : 

jmp  <ea> 

where 

<ea>  is  one  of  the  addressing  modes  listed  below 

Operation : 

<ea>  — >  PC 


Description : 

Execution  resumes  at  <ea>. 

If  jm.p  follows  a  rorg  directive,  a  jump  to  m.emory  abso 
lute  is  converted  to  a  branch. 


Example : 


here : 


jmp  here 
jmp  r ( 0 : 0 ) 
jmp  (1:150)0 


Addressing  Modes: 

<ea>:  m,r,mi,pcr 


Format : 

I  0250 


I'P]  {|  H8A2 


H85A4 


}|  operands 


BRA 


Branch 


BRA 


Syntax : 

bra  <ev> 

where : 

<ev>  is  one  of  the  addressing  modes  listed  below 

Operation: 

PC  +  <ev>  — >  PC 

Description : 

Execution  resumes  at  the  sum  of  the  program  counter  and  the 
effective  value. 

Example : 


bra  100 

Addressing  Modes: 

<ev>:  a,r 

Format : 

I  0250  I  jT7  I H8A5 1 . . . | H8A6 |  }  ) operands | 
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IF 


IF:  Conditional  Jump/Branch 


IF 


Syntax : 

if  R  <rop>  <ev>,M 
if  <bop>  <ea>,M 

where : 

<rop>  is  a  relational  operator 
<bop>  is  a  test  operator  • 

<ea>  and  <ev>  are  one  of  the  addressing  modes  listed  below 
Operation : 

if  R  <rop>  <ev>  then 
M  — >  PC 

if  <taop>  <ea>  then 
M  — >  PC 


Description : 


If  the  comparison  is  true,  execution  resumes  at  M;  other- 


wise, with 

the  next 

instruction. 

Example ; 

move 

{int,10} ,r  (0:0) 

1  oop ; 

if 

r(0:0)  <  {int,l},done 

sub 

{ int , 1 } , r (0 : 0 ) 

jmp. 

loop 

done : 

if 

int  data, loop 

data 

ds 

1 

Addressing 

Modes : 

R:  r 


<ev> :  r,i 
<ea>:  r,m 
M:  m,pcr 


Format : 


i  0250  I 


{  !  58A7  [  ,  I  58A^  ,  I  58AB 


,  1  58  AC! 

, 1 48AF 

,  1  48B0 

1  ,  |48B3 

,  1  48B4 

operands | 


IFTE 


If-Then-Else :  Conditional  Jump/Branch 


IFTE 


Syntax : 

if  R  <rop>  <ev>,Mx,My 
if  <bop>  <ea>,Mx,My 

where : 

<rop>  is  a  relational  operator 
<bop>  is  a  test  operator 

<ea>  and  <ev>  are  one  of  the  addressing  modes  listed  below 
Operation : 

if  R  <rop>  <ev>  then 
Mx  — >  PC 

else 

My  — >  PC 

if  <bop>  <ea>  then 
Mx  — >  PC 

else 

My  — >  PC 
Description : 


If  the 

comparison 

is  true,  execution  resumes 

otherwise , 

at  My. 

Example : 

if 

r(0:0)  >  r (0 : 1 ), easel , case2 

stuff : 

move 

r (0 :0) ,data 

easel : 

jsr 

f irst , s (0) 

if 

stop 

int  r (0 : 0) , easel 

case2 : 

jsr 

stop 

second, s (0) 

Addressing 

Modes : 

R:  r 

<ev>:  : 

r,  i 

<ea>:  : 

r  ,m 

Mx:  m,pcr 
My:  m»pcr 


o 


JSR 


Jump  Subroutine 


J 


Syntax : 

jsr  <ea>,S 

where : 

<ea>  is  one  of  the  addressing  modes  listed  below 

Operation : 

PC  — >  S 
<ea>  — >  PC 

Description : 

The  program  counter  is  pushed  onto  stack  S,  and  execu¬ 
tion  resumes  at  <ea>. 

Following  a  rorg  directive,  memory  absolute  is  converted 
automatically  to  program  counter  relative. 

Example : 

jsr  incr,s{0) 

Addressing  Modes: 

<ea>:  m,mi , r ,pcr , S :  s 


Format : 


. . . I H8B$  I  }  1  operands ] 


BSR 


Branch  Subroutine 


Syntax : 

bsr  <ev>,S 

where : 

<ev>  is  one  of  the  addressing  modes  listed  below 

Operation : 

PC  — >  S 

PC  +  <ev>  — >  PC 
Description : 

The  program  counter  is  pushed  onto  stack  S,  and  execu 
tion  resumes  at  the  sum  of  the  program,  counter  and  <ev>. 

Example : 


bsr  r ( 1 : 0 ) , s ( 0) 

Addressing  Modes; 

<ev>:  r,a  S:  s 


Format : 


RTS 


Return  from  Subroutine 


Syntax : 

rts  S 

Operation : 

S  — >  PC 

Description : 

Execution  resumes  at  the  address  popped  from  stack  S 
Example : 

incre:  add  { int , 1} , r (0 : 0) 

rts  s(0) 


Addressing  Modes: 
S:  s 


Format : 
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in 
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OPEN 


Open  a  File 


OPEN 


Syntax: 

open  S 

Operation : 

S  — > 

Description : 

To  open  a  file,  four  file  parameters  must  be  pushed  on 
the  stack,  in  proper  order,  before  the  open  instruction  is 
invoked.  These  attributes  are:  a  string  atom  for  the 
filename,  a  file  descriptor  atom,  an  integer  atom  for  the 
access  mode,  and  an  integer  atom  for  the  data  type  (raw  or 
AM  typed  values).  The  open  instruction  pops  these  parameters 
off  the  stack  and  opens  the  file.  All  future  file  operations 
are  referenced  by  the  file  descriptor. 

Example : 

datafile  equ  {file, 3} 

push  { string ," filename" }, s ( 0 ) 
push  (dataf ile} , s  (0) 
push  {int,0},s(0) 
push  {int,0},s(0) 
open  s(0) 


Addressing  Modes: 
S :  s 


Format : 
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CLOSE 


Close  a  File 


CLOSE 


Syntax : 

close  S 

Operation : 

S  — > 

Description : 

The  file  descriptor  atom  must  first  be  pushed  on  the  stack. 
The  close  instruction  pops  the  stack  and  closes  the  file. 

Example : 

datafile  equ  {file, 3) 

push  (dataf ile} , s (0) 
close  s(0) 


Addressing  Modes: 
S:  s 


Format : 


*  -  *  ■ 


READ 


Read  a  File 


READ 


Syntax : 

read  S 

Operation : 

S  — > 

Description : 

The  file  descriptor  atom  must  first  be  pushed  on  the  stack 
The  memory  address  atom  for  the  destination  buffer  cell  is 
pushed  next.  The  read  instruction  pops  these  parameters  off 
the  stack  and  puts  the  next  file  cell  in  the  destination 
buffer . 

Example : 


datafile 

equ 

{file, 3} 

push 

{datafile } , s { 0) 

push 

{ addr ,data } , s ( 0 ) 

read 

s{0) 

data 

ds 

100 

Addressing  Modes: 


Format : 


WRITE 


Write  to  File 


WRITE 


Syntax : 

write  S 

Operation : 

S  —  > 

Description: 

The  file  descriptor  atom  must  first  be  pushed  on  the  stack 
The  memory  address  atom  for  the  source  buffer  cell  is  pushed 
next.  The  write  instruction  pops  these  parameters  off  the 
stack  and  puts  the  contents  of  the  source  buffer  cell  into 
the  next  file  cell. 

Example : 


datafile 

equ 

{file,.!} 

push 

(datafile) , s (0) 

push 

{ addr , data  > , s ( 0 ) 

write 

s(0) 

data 

dc 

{ string, "hello  world") 

Addressing  Modes: 


Format : 


WRITE 


Write  a  Value  to  the  Queue 


WRITE 


Syntax ; 

write<ea> , Q 


where : 

<ea>  is  one  of  the  addressing  modes  listed  below 

Operation: 

Source  — >  Q 

Description : 

The  source  value  is  written  onto  queue  Q.  The  programmer 
has  no  access  to  the  queue  pointer. 

Example : 

write  {nat. 17 } ,q  (0) 
write  r  (0  : 10)  ,  q  (1) 

Addressing  Modes: 

<ea>  :  m, r , i , q 
Q:  q 


Format : 


READ 


Read  a  Value  from  the  Queue 


Syntax : 

read  Q,<ea> 

where 

<ea>  is  one  of  the  addressing  modes  listed  below 

Operation: 

Q  — >  destination 

Description : 

The  source  value  is  read  from  the  queue  Q  and  stored  at 
<ea>.  The  programmer  has  no  access  to  the  queue  pointer. 

It  is  an  error  to  attempt  to  read  a  value  from  an  empty  queue 

Example : 

read  q (0 ) , r ( 0 : 1) 
read  q (0) ,data 
data:  dsl 

Addressing  Modes: 

Q:  q 

<ea>  :  m,r 
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Format : 


DELETE 


Delete  the  Front  Value  of  the  Queue 


DELETE 


Syntax : 

delete  Q 

Operation : 

Q  — > 

Description : 

The  front  value  of  queue  Q  is  removed.  It  is  an  error 
to  attempt  to  remove  the  front  value  of  an  empty  queue. 

Example : 


delete  q(0) 


Addressing  Modes: 
Q:  q 
I 

Format : 


0250  I  lYi  I  2898 
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OPEN 


Open  the  Database 


Syntax: 

open  D 

Operation : 

D  — > 

Description : 

A  database  identifier  is  required  to  open  the  databse. 
All  future  operations  are  referenced  by  this  identifier. 

Example : 

open  { database, databaseid} 


Addressing  Modes: 

D:  i 

Format ; 

I  0250  I  jT]  I 28C4 I  I  operand 
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CLOSE 


Close  the  Database 


CLOSE 


Syntax : 

close  D 

Operation : 

D  — > 

Description : 

The  database  identifier  is  required  to  close  the  database. 
Example : 

close {database , databaseid) 

Addressing  Modes: 

D;  i 


Format : 
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